(This refers to the Computer software called Delphi)
(This does not relate to Delphi Corp, a part of GM (General Motors) nor with Delphi Bankruptcy News, Delphi Bankruptcy Hearings)
In Search of Profits
It was the year 1995, when Borland Delphi v2 came out. Borland was losing market share on it's DBase for Windows Compiler, Borland Pardox...
DelphiHater remember buying a copy of Turbo Pascal 5 many years ago. Those were the days of BBS (Bulletin Board Services), Doors, CompuServe (anyone remembers GO BORL or GO TURBO?) and AOL.
The days before Windows...
In those days, it was GUI, database and networking. Then there was Clipper, DBase, Fox. If anyone still remembers, Zortech C++, AZTech C++, Microsoft Visual C++, Microsoft Professional Basic, Small Talk and those PC Magazine Batch file utilities and, ... the Turbo Family of products, TurboBasic, TurboPascal, TurboLisp, TurboC, TurboC++
Zortech C++ was a competitor, but still decent. Zortech got brought over by Norton/Symantech and then the author brought back the rights and renamed it Digital Mars C++. In those days, Zortech had TSR libraries, basic NetBui (now called Microsoft Sharing), basic Netware support and simple DBF support. It was still good and still good now.
AZTech C++ is now obsolete. Back then, it allowed simple GUI, and no database-facilities.
Microsoft Professional Basic had EGA support, some VGA support, simple database (MSBTREE) and networking (file-sharing). At least, it had DBF support, simple graphics.
Borland's Product Offering for DOS...
For Borland's product, you are left scratching your head... Borland had DBase, but no compiler, then there was Borland Paradox, but new language, then there was Borland C++ with TurboVision, but no database-back-end, and then, TurboPascal with TurboVision (for Pascal) and no database-back-end.
At least, with Borland C++, there were many companies involved with selling DBF-compatible libraries, many dos-based 80x40 console GUI entry applications, and network based file management libraries. With TurboVision vs. ObjectVision, or Borland Object Framework 4.0 (anyone used Borland C++ 4.0 or 4.5?).
With DBase, there was really succky DBase III or DBase IV "interpreter". DBase had syntax that was totally different from C++ or Pascal (or even FoxPro).
With Paradox, there was totally different query language with totally different DOS/Win16 languages. For example, there was DOS/Paradox (and add-on Borland C++/Borland Pascal using DPMI). it was really hard to use it, you needed Borland C++ with DPMI support, but the debugger was not working so well, then Borland Pascal with DPMI support.
The wierdest thing was lack of DBase support in TurboPascal. There was record, and file-IO, but little or no DBF support. You can check Garbo's FTP (or SimTel old Pascal ZIP files).
Borland "promised" DBase support in TurboPascal 8.0 (or Delphi 1.0).
The road to data is long and wondering...
In short:
DBase = no compiler, decent DBase access, your customer gets sources and you get shafted.
TurboPascal 7 = great language, good GUI, no database or file-sharing in DOS.
Borland Pascal 7 with DPMI + Paradox DPMI + TurboVision = when will you get paid?
Borland C++ 4 + Dos Power Pack + TurboVision + (Paradox DPMI|DBF DPMI) = costs alot of money and lots of code to write for Novell Netware support.
Out-Foxed and Clipped
I've always wondering how FoxPro did it, and Clipper did it. They were really great products. For FoxPro, there was FoxBase, a popular language which allows FoxPro/DOS users to code PRG (program) files. Then Clipper allowed all-in-one GUI + Edit screen + Database + Network support. Really great.
To make the equivalents for Clipper in TurboC++/ or TurboPascal would take "ages" to do. It would probably take so long that Windows came out, the TurboPascal guys were still making DOS applications.
DOS/DPMI, OVL, EMS/XMS
The advent of DPMI brought some interesting things. The first, was breaking the 640kb limit with truely "sane" programming methods. Formerly, it was calling Interrupt 2F/XML or Int 2F/EMS services and doing low-level memory swapping. There was also Overlays, where disk-based swapping would occur.
In Dbase, FoxPro, Clipper, much of it was handled automatically (depending on which memory you used). Interestingly enough, Microsoft C++ had swapping overlays and Microsoft Basic had Basic Overlays. DelphiHater remembers using the funny Microsoft BMM (Basic Memory Manager), MSBTree along with decent file-sharing support.
In Borland C++, you had to purchase the DPMI "power-pack" or DPMI/32 goodies. TurboVision half worked in DPMI mode, and the memory pointer issues were hard to debug. In TPX/DPMI, or BPX.exe, you could create a TurboPascal EXE file which used Borland's DPMI implementation.
The most interesting thing is you could create 16-bit DOS-mode DLLs which could be used in DOS/Windows/OS2 16-bits environment, and also interesting DMPI-enabled environment, such as FoxPro 2.61 run-time, that is, you use FoxPro 2.61/DMPI with your TurboPascal EXE. It was an interesting combination, a Fox-Pro back-end with front-end TurboPascal/DMPI front-end.
Not to be out-done, Borland published Borland Paradox integration toolkit, with Paradox DLLs to be linked to your TurboPascal/DPMI or TurboC++/DPMI EXE file.
Pandara's Box
With the advent of Paradox and Dbase, this opened such a rift that brought Borland's fall. Your reviewer many years ago used to get "scare-mail" from other DBase consultants that Borland was not going to maintain Aston-Tate DBase III and convert DBase to Paradox instead.
It was the waiting for DBase IV compiler, Windows-version, (anyone heard of the ill-fated Paradox-compiler?) or the dizzy mix of announcements that followed.
Between DBF/3, DBF/4, Paradox, Fox21, Fox25, Fox26, DBF/4+Clipper, FlatFile, ObjectVision, TurboVision, BTrieve
The biggest problem with DBF/3, DBF/4 was lost or data corruption. If you are not careful in DBase III/IV, you could get corrupted files. Ditto with Paradox.
From your reviewer's personal experience, almost every day, be it, in DOS environments, there would be some corrupted files, or lost clusters, or FAT issues. Almost daily backups, copying to diskette-upon-diskettes were the norm.
The funny thing was DBF/4+Clipper, Fox21/Fox25/Fox26 never had, or at least, those problems. Clipper would auto-detect environment and then lock file accordingly, and would write-shared or have file read/write-locks.
anyone still remembers:
[CONFIG.SYS]
FILES=255
SHARE=100
Borland was touting TurboVision/ObjectVision/ObjectWindows persistent "objects" along with serialization, semaphores. The funny thing is, where's the object-locking and object-unlocking? DelphiHater does not remember any TFileLock or TObjLock or TSemaphore classes during those days. On the SimTel/ COMPUSERVE forums or BBS during those days, a bunch of people wrote the NETBUI, IPX/SPX, MSSHARE compatible code for this. It was dizzing mix, You had to detect NetBios, or IPX/SPX (call into IPX/ODI) or MSSHARE.
Then there was BTrieve (now called Pervasive/SQL) which was very decent database-system from Novell Netware. Your reviewer could not exactly understand how to use it in TurboPascal, since the SDK was read-mode with TSR calls, and the DPMI version worked with Windows-only DLLs (which defeated the purpose of DPMI/DLLs because it required floating-point DPMI).
Back in those old days, you could buy a "dumb terminal" and communicate via ansi.sys, "telnet" to the Unix-server. And obviously, not to be out-done, there was those legacy BBS/DOOR type applications. There was FoxBase UNIX-datbase server, Clipper/Unix (or now called Computer Associates CAVO-Unix).
The most strangest winner as FoxBase, as it could scale from single-user to network to nearly limitless number of users via Unix/dumb-terminal. Clipper came second, then DBase came second, but with bad support from Ashton-Tate/Borland...
Then came Windows...
With Windows, almost everything started to unravel for Borland...
With Borland Paradox for Windows 1.0, it was at times, really slow, DBase was still DOS-based until Access 2.0 came out (or got sold as an independing company), then Borland Paradox became Corel Paradox.
Borland tried to "unify" DBase, Paradox and Fox (badly done) database support into the Borland Database Engine (BDE). This was an about-face for Borland. There were numerous unfixed errors, including bad DBase errors, slow Paradox support, Foxpro file support.
From Borland C++ 4.0/4.5 for Windows, at least, there were faster third-party libraries which allowed faster access to DBF files, such as Sequiter CodeBase.
For Borland Pascal, it came from CodeBase/DLL support (really wierd, IMHO) or Borland Paradox Integration toolkit (another wierd thing). End result = constant re-writing, re-writing, and constant re-writing.
Borland Delphi 2.0 (32-bits), Delphi 3.0, Delphi 4,5,6,7...
The good old days...
With Borland Delphi 3.0, at least, things were starting to look promising. There was decent DBF support, decent Fox21 support, and ODBC support when you needed it (via BDE).
With Borland Delphi 3.0, it was much better than Visual Basic 4 (VB3 was 16-bits) by many respects, but then, some... For example, while VB4 suffered from not able to create OCX's, it could create simple classes, good access to ODBC and other Visual Basic class libraries.
The problems were the same - In order to get good GUI, the DBGrid (and still same to Delphi 2009) looks the same since nearly 10 years ago. In order to get good edit controls, you needed to buy tons and tons of libraries to get moving.
Then came the price increases, from US$149 to thousands. Borland suddenly had name-change to Inprise and then Inprise C++, Inprise Delphi 4,5,6,7 but they never fixed any bugs. Literally.
Each new version of Delphi was small bug fixes, and more new features. From Delphi 3 to Delphi 4, there were plenty of new features (most useless, IMHO) and few bug fixes, then most features were moved to the Enterprise version, then "Architect", then "Enterprise-Architect" version (Delphi 7).
Much ADO about nothing
In Delphi 6, ODBC came in Delphi Enterprise, or as an add-on pack in Delphi 6 Professional. How stupid is that? During that time, there were "interesting" third-party libraries such as ODBC98, Adonis, Islamov Ado, WinSoft ADO, KA-ADO, GM ADO, to name a few. All of them have this in common: All the companies mentioned have poor or bad implementations or not-frequently updated libraries. With Delphi 7 onwards, ADO became default, but the older library (DAO, ODBC) was via TLB export. Even the low-level ODBC was not very clearly implemented in Delphi.
(Surprisingly, the BetterAdoDataSet library is now almost abandonware. You can find a free update to Delphi 2009, but don't count on it for production quality.)
Fired-up over Firebird
In Delphi 5 Enterprise, Interbase 5.0 came out. Your reviewer could not understand how "difficult" it was to access Interbase 5.0/6.0 with Delphi. It was either:
Interbase <--> BDE <--> EXE
Interbase <--> EasySoft ODBC <--> BDE <--> EXE
Interbase <--> IBX + EXE
Interbase 5.0 came with no ODBC driver, or a driver from PVCS Intersolv ODBC solutions. It was later replaced with a US$99 per seat EasySoft ODBC driver ... then Interbase became open-source Firebox 0.9, then Firebird 1.0, 1.5, 2.0, then 2.1...
DelphiHater could never understand why the BDE/IBX that came with Delphi was soooo lame, or Jeff Overcash (there's a person called Jeff "Undercash" who lampoons him on the Borland newsgroups) could not update the IBX to use Firebird 2.xx. Since FireBird is free, why do I have to pay for a "working" and correct DBExpress driver for? ditto for database manager, ODBC driver, log manager, search add-on, backup utility? with all those "added development costs", it seems MSSQL or even MySQL is cheaper... There is IBObjects, but that's an annual subscription...
Outfoxed over FoxPro
Your reviewer could never understand how Borland's implementation of Foxpro, DBF/Clipper could be so screwed up. If a team of software developer had 10 years to fix bugs, and ample amount of cash, they would have fixed every damn bug with the BDE and make it good. Borland recommends to use a third-party library to access FoxPro, such as VistaSoftware's Apollo, or Advantage Database (now owned by Sybase).
If you have ever used Apollo from Vista Software (formerly Luxent, formerly Apollo software) you could hear cries about how they still do not support FoxPro 2.6 (amazing).
The real Paradox
If you don't learn about history, your life will be one big mystery. With Paradox, other than access via BDE, is there any other library (other than ODBC) to access Paradox? You could find one, but does not support SQL, or password-protected Paradox files.
Your reviewer wonders what's the worth of Paradox? With Paradox, you had *.px, *.do, *.qbe, and whole host of files. Now remember the old days, when file-handles were precious and if you ran out of file-handles, your database ended up in trouble.
With each Paradox file using up 4 extensions (PX, IDX, DO, QBE and possibly more) 255/4 = 63. You could build upto 60 unique tables for Paradox before running out of file-shares, but wait, since because DOS/Windows uses say, 30 or 40, then, you end up with an average of 30 unique files you can open at one time. Give and take, 50 files. If you programed your application right, this would not be an issue, but over the network, the troubles start happening.
Did anyone see any good working Paradox-based applications? I've seen plenty of DBF/Clipper/Access/Fox applications.
Going Boldly where no programmer has gone before
Bold for Delphi, which was brought over by Borland was in the ridiculously expensive version of Delphi 7, and came partial sources. The people were literally dying to upgrade their Bold for Delphi applications for Delphi 2009, or at least, provide updates for it. Bold for Delphi, on one hand, provided object-persistence support and model-mapping, but was side-lined in favour of "Together" modelling. Together was in the most expensive version of Delphi... Those people who brought Delphi-Pro never could use it, ever. nor could they buy it, since it came with Delphi/arch.
Another curious competitor - InstantObjects came out long time ago has been languishing ever since. There are few developments for it.
IntraNot
IntraWeb, the curious "VCL for Web" which it seems, nobody uses, or at least, in practice. IntraWeb was really good, but I have yet to see any free IntraWeb "blogs" component, or good intraweb component. The Delphi/Pro version came with 5-user version and the Enterprise version came with what seems like the older version of IntraWeb. Each new version of Delphi results in a new version of IntraWeb and never-ending subscriptions to get the latest updates from AtoZed. There are so few third-party add-ons for IntraWeb, and nearly all of them costs money, each sold separately. If IntraWeb was popular, there would be thousands of free scripts (see HotScripts and other sites for free PHP Scripts) and add-ons, but sadly, there are very few...
DelphiHater challenges anyone to integrate, say, any blog, content manager (Drupal, WordPress, Mambo, PHP Nuke) HTML templates and try to try to make their IntraWeb sites look beautiful (The sad reality is you really cannot control the HTML emitted) or use Frames or cross-integrate with PHP/Java/Ruby/ASP. Did anyone try to beautify the grids or edit controls? Try making a "free-form" website with IntraWeb :)
Not yet, Baby!
With Delphi.NET, and C# Builder, DelphiHater remembers the curiously slow C# and Delphi.NET application while the C# version feels faster. Since Delphi.NET does not support Visual Studio's integration, those cool NET components could not be used in Delphi. With Delphi.NET 1.0, 1.1, Borland "dumped" their NET compiler in favour of RemObject's compiler.
Your reviewer would be hard-pressed to use Delphi.NET, because C# incurs no additional cost to use. You can give C# code and using a text-editor, and a big MSBuild Script, make an EXE or Website.
With Delphi for NET, the language is completely different from Delphi, and funny, it is easier to convert from Delphi to C# (due to plenty of automated programs) than to convert from Delphi/Win32 to Delphi/NET.
With all those "price increases", how much does it cost to add another person to the Development team? DelphiHater would shudder to employ a team of people, the computer cost, Compiler cost, the 3rd-party cost, the VCS cost, and so on...
[End of Part 1]
(This does not relate to Delphi Corp, a part of GM (General Motors) nor with Delphi Bankruptcy News, Delphi Bankruptcy Hearings)
In Search of Profits
It was the year 1995, when Borland Delphi v2 came out. Borland was losing market share on it's DBase for Windows Compiler, Borland Pardox...
DelphiHater remember buying a copy of Turbo Pascal 5 many years ago. Those were the days of BBS (Bulletin Board Services), Doors, CompuServe (anyone remembers GO BORL or GO TURBO?) and AOL.
The days before Windows...
In those days, it was GUI, database and networking. Then there was Clipper, DBase, Fox. If anyone still remembers, Zortech C++, AZTech C++, Microsoft Visual C++, Microsoft Professional Basic, Small Talk and those PC Magazine Batch file utilities and, ... the Turbo Family of products, TurboBasic, TurboPascal, TurboLisp, TurboC, TurboC++
Zortech C++ was a competitor, but still decent. Zortech got brought over by Norton/Symantech and then the author brought back the rights and renamed it Digital Mars C++. In those days, Zortech had TSR libraries, basic NetBui (now called Microsoft Sharing), basic Netware support and simple DBF support. It was still good and still good now.
AZTech C++ is now obsolete. Back then, it allowed simple GUI, and no database-facilities.
Microsoft Professional Basic had EGA support, some VGA support, simple database (MSBTREE) and networking (file-sharing). At least, it had DBF support, simple graphics.
Borland's Product Offering for DOS...
For Borland's product, you are left scratching your head... Borland had DBase, but no compiler, then there was Borland Paradox, but new language, then there was Borland C++ with TurboVision, but no database-back-end, and then, TurboPascal with TurboVision (for Pascal) and no database-back-end.
At least, with Borland C++, there were many companies involved with selling DBF-compatible libraries, many dos-based 80x40 console GUI entry applications, and network based file management libraries. With TurboVision vs. ObjectVision, or Borland Object Framework 4.0 (anyone used Borland C++ 4.0 or 4.5?).
With DBase, there was really succky DBase III or DBase IV "interpreter". DBase had syntax that was totally different from C++ or Pascal (or even FoxPro).
With Paradox, there was totally different query language with totally different DOS/Win16 languages. For example, there was DOS/Paradox (and add-on Borland C++/Borland Pascal using DPMI). it was really hard to use it, you needed Borland C++ with DPMI support, but the debugger was not working so well, then Borland Pascal with DPMI support.
The wierdest thing was lack of DBase support in TurboPascal. There was record, and file-IO, but little or no DBF support. You can check Garbo's FTP (or SimTel old Pascal ZIP files).
Borland "promised" DBase support in TurboPascal 8.0 (or Delphi 1.0).
The road to data is long and wondering...
In short:
DBase = no compiler, decent DBase access, your customer gets sources and you get shafted.
TurboPascal 7 = great language, good GUI, no database or file-sharing in DOS.
Borland Pascal 7 with DPMI + Paradox DPMI + TurboVision = when will you get paid?
Borland C++ 4 + Dos Power Pack + TurboVision + (Paradox DPMI|DBF DPMI) = costs alot of money and lots of code to write for Novell Netware support.
Out-Foxed and Clipped
I've always wondering how FoxPro did it, and Clipper did it. They were really great products. For FoxPro, there was FoxBase, a popular language which allows FoxPro/DOS users to code PRG (program) files. Then Clipper allowed all-in-one GUI + Edit screen + Database + Network support. Really great.
To make the equivalents for Clipper in TurboC++/ or TurboPascal would take "ages" to do. It would probably take so long that Windows came out, the TurboPascal guys were still making DOS applications.
DOS/DPMI, OVL, EMS/XMS
The advent of DPMI brought some interesting things. The first, was breaking the 640kb limit with truely "sane" programming methods. Formerly, it was calling Interrupt 2F/XML or Int 2F/EMS services and doing low-level memory swapping. There was also Overlays, where disk-based swapping would occur.
In Dbase, FoxPro, Clipper, much of it was handled automatically (depending on which memory you used). Interestingly enough, Microsoft C++ had swapping overlays and Microsoft Basic had Basic Overlays. DelphiHater remembers using the funny Microsoft BMM (Basic Memory Manager), MSBTree along with decent file-sharing support.
In Borland C++, you had to purchase the DPMI "power-pack" or DPMI/32 goodies. TurboVision half worked in DPMI mode, and the memory pointer issues were hard to debug. In TPX/DPMI, or BPX.exe, you could create a TurboPascal EXE file which used Borland's DPMI implementation.
The most interesting thing is you could create 16-bit DOS-mode DLLs which could be used in DOS/Windows/OS2 16-bits environment, and also interesting DMPI-enabled environment, such as FoxPro 2.61 run-time, that is, you use FoxPro 2.61/DMPI with your TurboPascal EXE. It was an interesting combination, a Fox-Pro back-end with front-end TurboPascal/DMPI front-end.
Not to be out-done, Borland published Borland Paradox integration toolkit, with Paradox DLLs to be linked to your TurboPascal/DPMI or TurboC++/DPMI EXE file.
Pandara's Box
With the advent of Paradox and Dbase, this opened such a rift that brought Borland's fall. Your reviewer many years ago used to get "scare-mail" from other DBase consultants that Borland was not going to maintain Aston-Tate DBase III and convert DBase to Paradox instead.
It was the waiting for DBase IV compiler, Windows-version, (anyone heard of the ill-fated Paradox-compiler?) or the dizzy mix of announcements that followed.
Between DBF/3, DBF/4, Paradox, Fox21, Fox25, Fox26, DBF/4+Clipper, FlatFile, ObjectVision, TurboVision, BTrieve
The biggest problem with DBF/3, DBF/4 was lost or data corruption. If you are not careful in DBase III/IV, you could get corrupted files. Ditto with Paradox.
From your reviewer's personal experience, almost every day, be it, in DOS environments, there would be some corrupted files, or lost clusters, or FAT issues. Almost daily backups, copying to diskette-upon-diskettes were the norm.
The funny thing was DBF/4+Clipper, Fox21/Fox25/Fox26 never had, or at least, those problems. Clipper would auto-detect environment and then lock file accordingly, and would write-shared or have file read/write-locks.
anyone still remembers:
[CONFIG.SYS]
FILES=255
SHARE=100
Borland was touting TurboVision/ObjectVision/ObjectWindows persistent "objects" along with serialization, semaphores. The funny thing is, where's the object-locking and object-unlocking? DelphiHater does not remember any TFileLock or TObjLock or TSemaphore classes during those days. On the SimTel/ COMPUSERVE forums or BBS during those days, a bunch of people wrote the NETBUI, IPX/SPX, MSSHARE compatible code for this. It was dizzing mix, You had to detect NetBios, or IPX/SPX (call into IPX/ODI) or MSSHARE.
Then there was BTrieve (now called Pervasive/SQL) which was very decent database-system from Novell Netware. Your reviewer could not exactly understand how to use it in TurboPascal, since the SDK was read-mode with TSR calls, and the DPMI version worked with Windows-only DLLs (which defeated the purpose of DPMI/DLLs because it required floating-point DPMI).
Back in those old days, you could buy a "dumb terminal" and communicate via ansi.sys, "telnet" to the Unix-server. And obviously, not to be out-done, there was those legacy BBS/DOOR type applications. There was FoxBase UNIX-datbase server, Clipper/Unix (or now called Computer Associates CAVO-Unix).
The most strangest winner as FoxBase, as it could scale from single-user to network to nearly limitless number of users via Unix/dumb-terminal. Clipper came second, then DBase came second, but with bad support from Ashton-Tate/Borland...
Then came Windows...
With Windows, almost everything started to unravel for Borland...
With Borland Paradox for Windows 1.0, it was at times, really slow, DBase was still DOS-based until Access 2.0 came out (or got sold as an independing company), then Borland Paradox became Corel Paradox.
Borland tried to "unify" DBase, Paradox and Fox (badly done) database support into the Borland Database Engine (BDE). This was an about-face for Borland. There were numerous unfixed errors, including bad DBase errors, slow Paradox support, Foxpro file support.
From Borland C++ 4.0/4.5 for Windows, at least, there were faster third-party libraries which allowed faster access to DBF files, such as Sequiter CodeBase.
For Borland Pascal, it came from CodeBase/DLL support (really wierd, IMHO) or Borland Paradox Integration toolkit (another wierd thing). End result = constant re-writing, re-writing, and constant re-writing.
Borland Delphi 2.0 (32-bits), Delphi 3.0, Delphi 4,5,6,7...
The good old days...
With Borland Delphi 3.0, at least, things were starting to look promising. There was decent DBF support, decent Fox21 support, and ODBC support when you needed it (via BDE).
With Borland Delphi 3.0, it was much better than Visual Basic 4 (VB3 was 16-bits) by many respects, but then, some... For example, while VB4 suffered from not able to create OCX's, it could create simple classes, good access to ODBC and other Visual Basic class libraries.
The problems were the same - In order to get good GUI, the DBGrid (and still same to Delphi 2009) looks the same since nearly 10 years ago. In order to get good edit controls, you needed to buy tons and tons of libraries to get moving.
Then came the price increases, from US$149 to thousands. Borland suddenly had name-change to Inprise and then Inprise C++, Inprise Delphi 4,5,6,7 but they never fixed any bugs. Literally.
Each new version of Delphi was small bug fixes, and more new features. From Delphi 3 to Delphi 4, there were plenty of new features (most useless, IMHO) and few bug fixes, then most features were moved to the Enterprise version, then "Architect", then "Enterprise-Architect" version (Delphi 7).
Much ADO about nothing
In Delphi 6, ODBC came in Delphi Enterprise, or as an add-on pack in Delphi 6 Professional. How stupid is that? During that time, there were "interesting" third-party libraries such as ODBC98, Adonis, Islamov Ado, WinSoft ADO, KA-ADO, GM ADO, to name a few. All of them have this in common: All the companies mentioned have poor or bad implementations or not-frequently updated libraries. With Delphi 7 onwards, ADO became default, but the older library (DAO, ODBC) was via TLB export. Even the low-level ODBC was not very clearly implemented in Delphi.
(Surprisingly, the BetterAdoDataSet library is now almost abandonware. You can find a free update to Delphi 2009, but don't count on it for production quality.)
Fired-up over Firebird
In Delphi 5 Enterprise, Interbase 5.0 came out. Your reviewer could not understand how "difficult" it was to access Interbase 5.0/6.0 with Delphi. It was either:
Interbase <--> BDE <--> EXE
Interbase <--> EasySoft ODBC <--> BDE <--> EXE
Interbase <--> IBX + EXE
Interbase 5.0 came with no ODBC driver, or a driver from PVCS Intersolv ODBC solutions. It was later replaced with a US$99 per seat EasySoft ODBC driver ... then Interbase became open-source Firebox 0.9, then Firebird 1.0, 1.5, 2.0, then 2.1...
DelphiHater could never understand why the BDE/IBX that came with Delphi was soooo lame, or Jeff Overcash (there's a person called Jeff "Undercash" who lampoons him on the Borland newsgroups) could not update the IBX to use Firebird 2.xx. Since FireBird is free, why do I have to pay for a "working" and correct DBExpress driver for? ditto for database manager, ODBC driver, log manager, search add-on, backup utility? with all those "added development costs", it seems MSSQL or even MySQL is cheaper... There is IBObjects, but that's an annual subscription...
Outfoxed over FoxPro
Your reviewer could never understand how Borland's implementation of Foxpro, DBF/Clipper could be so screwed up. If a team of software developer had 10 years to fix bugs, and ample amount of cash, they would have fixed every damn bug with the BDE and make it good. Borland recommends to use a third-party library to access FoxPro, such as VistaSoftware's Apollo, or Advantage Database (now owned by Sybase).
If you have ever used Apollo from Vista Software (formerly Luxent, formerly Apollo software) you could hear cries about how they still do not support FoxPro 2.6 (amazing).
The real Paradox
If you don't learn about history, your life will be one big mystery. With Paradox, other than access via BDE, is there any other library (other than ODBC) to access Paradox? You could find one, but does not support SQL, or password-protected Paradox files.
Your reviewer wonders what's the worth of Paradox? With Paradox, you had *.px, *.do, *.qbe, and whole host of files. Now remember the old days, when file-handles were precious and if you ran out of file-handles, your database ended up in trouble.
With each Paradox file using up 4 extensions (PX, IDX, DO, QBE and possibly more) 255/4 = 63. You could build upto 60 unique tables for Paradox before running out of file-shares, but wait, since because DOS/Windows uses say, 30 or 40, then, you end up with an average of 30 unique files you can open at one time. Give and take, 50 files. If you programed your application right, this would not be an issue, but over the network, the troubles start happening.
Did anyone see any good working Paradox-based applications? I've seen plenty of DBF/Clipper/Access/Fox applications.
Going Boldly where no programmer has gone before
Bold for Delphi, which was brought over by Borland was in the ridiculously expensive version of Delphi 7, and came partial sources. The people were literally dying to upgrade their Bold for Delphi applications for Delphi 2009, or at least, provide updates for it. Bold for Delphi, on one hand, provided object-persistence support and model-mapping, but was side-lined in favour of "Together" modelling. Together was in the most expensive version of Delphi... Those people who brought Delphi-Pro never could use it, ever. nor could they buy it, since it came with Delphi/arch.
Another curious competitor - InstantObjects came out long time ago has been languishing ever since. There are few developments for it.
IntraNot
IntraWeb, the curious "VCL for Web" which it seems, nobody uses, or at least, in practice. IntraWeb was really good, but I have yet to see any free IntraWeb "blogs" component, or good intraweb component. The Delphi/Pro version came with 5-user version and the Enterprise version came with what seems like the older version of IntraWeb. Each new version of Delphi results in a new version of IntraWeb and never-ending subscriptions to get the latest updates from AtoZed. There are so few third-party add-ons for IntraWeb, and nearly all of them costs money, each sold separately. If IntraWeb was popular, there would be thousands of free scripts (see HotScripts and other sites for free PHP Scripts) and add-ons, but sadly, there are very few...
DelphiHater challenges anyone to integrate, say, any blog, content manager (Drupal, WordPress, Mambo, PHP Nuke) HTML templates and try to try to make their IntraWeb sites look beautiful (The sad reality is you really cannot control the HTML emitted) or use Frames or cross-integrate with PHP/Java/Ruby/ASP. Did anyone try to beautify the grids or edit controls? Try making a "free-form" website with IntraWeb :)
Not yet, Baby!
With Delphi.NET, and C# Builder, DelphiHater remembers the curiously slow C# and Delphi.NET application while the C# version feels faster. Since Delphi.NET does not support Visual Studio's integration, those cool NET components could not be used in Delphi. With Delphi.NET 1.0, 1.1, Borland "dumped" their NET compiler in favour of RemObject's compiler.
Your reviewer would be hard-pressed to use Delphi.NET, because C# incurs no additional cost to use. You can give C# code and using a text-editor, and a big MSBuild Script, make an EXE or Website.
With Delphi for NET, the language is completely different from Delphi, and funny, it is easier to convert from Delphi to C# (due to plenty of automated programs) than to convert from Delphi/Win32 to Delphi/NET.
With all those "price increases", how much does it cost to add another person to the Development team? DelphiHater would shudder to employ a team of people, the computer cost, Compiler cost, the 3rd-party cost, the VCS cost, and so on...
[End of Part 1]
No comments:
Post a Comment