In the mid 80s in the computer scenario the firm Ashton-Tate is one of main players among developers of business applications, experts and simple hobbyists. With DBIII, which is essentially a programmable database, it is possible to create in an easy and intuitive way databases, and also write procedures in a simple high-level language to manage them. DBIII had its own programming language with dozens of specific instructions aimed at the database management. It was therefore possible to use DBIII “directly” by giving one instruction at a time, or for repetitive tasks write to a file such instructions and then instruct DBIII to read the file and execute them sequentially. It was also possible to present menus of choice and then fed to inexperienced users a comprehensive management program, such as an order management and billing, inventory, warehouse management, etc..
In this way a company could buy the DBIII and then hire a programmer to design a whole management, perhaps by writing ad hoc procedures. Soon enterprising programmers began to offer these procedures ready-made or customized to one’s needs, to a market in rapid expansion and practically virgin. At the time there were just a few programmers and software, so the DBIII, which was infinitely more powerful, effective and easy than traditional programming languages, quickly gained a big market share. But there were a couple of drawbacks. Written procedures for DBIII required in order to be executed that DBIII was installed on the target computer, and if I remember correctly DBIII costed one million and a half italian lire (compared to today, at least three or four thousand euro), the procedures were also simple text files and any scoundrel could have copied and reused them hidden from the rightful author. What happened in reality was that almost everyone had a pirated copy of DBIII and a black market flourished about programs stolen from various companies. The nerds of the time had the opportunity to take possession of a number of programs and study them quietly, not to mention the large (for the time) literature on DBIII that completed the excellent manual accompanying the product (and of which nearly all naturally had an illegal photocopy). A note for non Italian readers: at the time in Italy the perception of the stealing of the software as a crime was non-existent, and the commercial behaviour of italian branches of software companies was to sell products at the highest price affordable by big or medium-sized companies. That is to say that either you stoled the software or you had no hope to gain access to it. Student or personal licenses were simply not available.. (I’m not justifying the stealing of software, as a programmer of course I am against it.)
Ashton-Tate had always refused to equip DBIII of a real application generator, detaching the language, ie procedures, from its interpreter DBIII. It would have been possible that way to generate executable programs from inside DBIII, to run them even on computers where DBIII was not installed, creating an executable impossible or at least very difficult to “unpack” to know what was inside. They could, but they did not see the interest to do so: such a move could have facilitated programmers but they cared only sell copies of DBIII, without realizing that now the DBIII owed his fortune mainly to programmers, and at least one form of obfuscation or pseudo-compilation or encryption was essential to protect the work of programmers, who resented having to give around their sweaty code in a non-protected way. The market was changing, and fewer and fewer people felt the need to directly use the DBIII, since the availability of software ready-made was large and growing, then the obligation to buy it came down to the need to be in compliance with the licenses’ use, but looked like a kind of heavy bribe that you had to pay to Ashton-Tate to run programs written for DBIII.
At the end of the 80s a couple of American companies were able to create compilers able to take the written procedures for DBIII and finally transform into stand-alone programs that do not require any additional component to be executed. It was revolution.
Nantucket Corp. introduced Clipper, and the other product I remember was called Quicksilver. Clipper gained the prevalence. It was very easily available in Italy, as usual as “unofficial copy”, accompanied by a basic but complete documentation, and also had some extra features that made it even more powerful a language, particularly a system to connect Clipper to the C language, making a powerful tool in the hands of both the occasional programmer, which could fill in simple procedures derived from DBIII, as well as the real expert programmer, who could romp around to do any type of application.
The first prey of Clipper were the millions of users of DBIII, almost only programmers, who could finally distribute their programs in the form of stand-alone executable, which made impossible for the end user to go back to the source (and then make changes), and also began to attract programmers who abandoned their traditional languages to switch to the new one. Clipper version S87 was done exceptionally well. It allowed to write multi-user programs, it was solid as a rock, almost bug-free, effective and relatively easy to learn (especially for those coming from DBIII). His relationship with the C did not make it too exotic for those who came from this language, and, as we have seen, these programmers had all the tools to connect Clipper to C, so they regarded it as a godsend.
Nantucket was acquired by Computer Associates, a software giant, at the top of his fame, when he had in the drawer two products more or less ready for the launch, which are version 5 of Clipper and Visual Object, the latter intended as the Clipper evolution in the new cyber world that was emerging, where mouse, windows and graphical interfaces were taking the place of the sad black screen of DOS.
CA released later Clipper version 5, which was in fact a further revolution: the language was reimplemented as a subset of something much more vast that now also included an object oriented language, which in the meantime was becoming established as the new programming paradigm. The “something” was more clearly resembling the plain C, although it retained its distinct identity. Also the true internal structure of the new Clipper showed itself, a collection of hundreds of distinct functions, and a “translator” which transformed the classic instructions DBIII to the corresponding “C-like” functions. Object-oriented programming and the presence of hundreds of new instructions made it appear as a small subset simplified the traditional language DBIII, and at this stage many programmers were astonished and perplexed. I must admit that I was converted to the new version of Clipper only when it reached version 5.2, and wrinkling my nose. I think it was 1991.
In the meanwhile, Ashton-Tate had launched DBIV, with little luck, and then tried to retrain in a Windows environment with dBase 5, but even that was not very successful and ultimately failed. Now, after several change of ownership Visual dBase survives, developed and marketed by a small independent company.
The best product after Clipper was probably Foxpro, which in some aspects was even better, and the Windows version, Visual Foxpro, was probably the best implementation of dBase language in such an environment. It is at this time that man begins to speak generically of xBase languages, as there were several products, all based on the old DBIII but with variations and different characteristics. The real problem was, however, how to adapt the dBase language to the new Windows-centric environment.
The Clipper compiler and other products designed for the DOS environment refers to a style of programming that is quite different from the operation of Windows (or any other GUI). The need to manage buttons, windows, maybe even multiple windows open at the same time in the same program, and the need to communicate with Windows leads to a programming model called event-driven, as opposed to traditional programming, called procedural, where each program does usually only one thing at a time according to a predetermined sequence. dBase V and Foxbase had solved in their own way, tracing a route and creating their own versions of the new xBase, with extensions for object-oriented programming and all the graphical stuff. CA Visual Object was released, the successor to Clipper, innovative and promising, though somewhat obscure and full of bugs that made it almost unusable.
At this point Microsoft came in, acquiring Visual FoxPro. The move appeared to be an acknowledgement toward Visual Foxpro as the best xBase tool available, and evidence that Microsoft had decided to enter the arena of xBase languages the front door. Many programmers bought Foxpro (including myself) happily thinking that the language would not have died and new developments would come. None of that. Soon the true Microsoft strategy became clear: he had bought Foxpro only to knock it down and redirect programmers to its proprietary alternatives. Foxpro was left to die slowly and is now no longer in the Microsoft catalog. The latest release is 2007.
But some rash began to work independently on Clipper: Clip4win was born, a Clipper extension that allowed you to connect to the Windows environment, (can’t remember the author). About the same time a certain Antonio Linares, a strong C programmer with very good knowledge of the inner workings of Windows fell in love with Clipper and, in turn, wrote an extension that called Fivewin. The beauty and depth of Fivewin are the simplicity of the language created by Linares (and his pard Francisco Pulpòn) to manage the Windows environment, the perfect integration of its extensions in the existing language and the fundamental quality of his work. Although Fivewin had a few bugs, the overall quality was very good and at acceptable cost: the product was an immediate success among programmers.
But in the meantime CA had almost abandoned Clipper, which remained a 16-bit compiler in a world striding towards the 32 and then the 64-bit, and it began to suffer from structural insurmountable limitations. Linares began to develop an independent compiler compatible with Clipper (and Fivewin of course) able to meet the challenges of the future. His vision was great and the personal effort probably immense. The big news was that Harbour (the new compiler) was born as an open source project, that is free to use by anyone. The last version released from CA was the Clipper 5.3b in 1997. The alternatives for the xBase programmers community consisted of a few rather expensive proprietary products, such as Alaska xBase, Flagship, Visual FoxPro and dBase V. None of these, however, seemed able to collect the inheritance of Clipper. Flagship was also the only cross-platform product, available both for Windows and Linux.
The idea of an Open Source compiler attracted a number of programmers and the system gradually began to take hold. Soon there was a Linux version, allowing a programmer to write a program and to be able to compile and run without major changes in the two environments. At one point the creature turned to his master, so to say. Just because the project was “free”, a group of programmers disagree with Linares lines to be followed in the development of the compiler and separated from the original project giving rise to xHarbour, which stands for extended Harbour (2001). Two versions are available, a paid and a free version, while Harbour is available only as a free product. The two projects, Harbour and xHarbour, have much in common as arising from the same trunk, but the differences are not just a few.
The current situation sees Harbour as a larger project and available for many different platforms, such as Windows, Linux, Mac OS X, MINIX 3, Windows CE, Pocket PC, Symbian, iPhone, QNX, VxWorks, OS/2/eComStation, BeOS / Haiku, AIX (in comparison, xHarbour only supports Windows and Linux). Through the contribution of many independent programmers the language now has a number of alternatives at the level of GUI, in addition to the aforementioned Fivewin (which is still in its pre-eminent position) and can connect to SQL server such as Oracle, PostgreSQL, MySQL etc.. and harness the power of today’s PC 32 or 64 bit. I use both compilers on Windows and only Harbour on Linux. The development is constant and the community of programmers is connected throughout the world through technical forums for discussion and mailing list.
Ho usato per anni DBIII compilato prima con summer87 e poi clipper5
Non sono professionista sono autodidatta (vecchio) ho fatto moltissimi rogrammi per migliorare la vita dei miei colleghi dagli anni 80 in poi quando nella nostra banca si andava sempre a penna. Vorrei sapere:
Come si formatta un hd per caricare win 98 e rispolverare clipper5. Ho un disco da 160 giga e non si installa è troppo grande.
Su win xp si può usare clipper 5 e come si fa
In caso contrario harbour come si usa?
Visto che mi sembri ferrato posso avere qualche delucidazione?
Grazie vivaclipper sempre
Clipper è un compilatore a 16 bit e genera applicativi a 16 bit, che non girano su Windows XP il quale è un sistema a 32 bit. Quindi potresti usare VMWare per creare una macchina virtuale e caricarci Windows 98. VMWare è disponibile in versione gratuita e funziona piuttosto bene. Attualmente ho un PC sul quale gira XP Professional come sistema host, ed esegue tre macchine virtuali. Ogni macchina virtuale si comporta come un PC vero e proprio, quindi ci si può caricare un sistema operativo e tutti i relativi programmi. Nel mio caso ho installato Linux Slackware 12.2, Windows 2000 e Windows XP Home. A parte questa soluzione, la cosa migliore è quella di utilizzare Harbour o xHarbour. Puoi scaricare quest’ultimo dal sito http://www.whosaway.com, gestito dal simpatico e disponibile Mel Smith (password XHB). In alternativa, puoi trovarlo sul sito ufficiale su sourceforge. Ti servirà anche un compilatore C, molti usano il Borland C di cui è disponibile una versione free (la 5.5.qualcosa, e anche, recentemente, la versione 6.qualcosa). xHarbour è disponibile sia sotto forma di sorgente, sia già compilato e pronto all’uso in versione Windows o Linux.
Ti conviene scaricare i binari già compilati, ti eviti la seccatura di ricompilare xHarbour e sei pronto per il tuo primo programma senza troppe complicazioni.
Se i tuoi programmi Clipper non fanno uso di librerie esterne (Superlib, Funcky etc.) non ti serve altro, viceversa ci potrebbero essere dei problemi, dato che le librerie fatte per Clipper non possono essere linkate con [x]Harbour dato che sono a 16 bit. Se hai i sorgenti delle librerie puoi ricompilarle, altrimenti bisogna vedere. Clipper Tools e Nanforum Toolkit sono state quasi completamente ricompilate e quindi disponibili nativamente. Harbour è attualmente molto più vasto di xHarbour e viene sviluppato ed aggiornato con maggiore frequenza. Risulta probabilmente un tantino più difficile da affrontare ma i due compilatori sono abbastanza simili in realtà. Ci sono forum, mailing list e manuali on-line per entrambi i compilatori. In lingua italiana non c’è molto, ma in inglese la situazione è abbastanza buona. Con entrambi i compilatori la compatibilità con il codice “puro Clipper” è del 100%, l’eseguibile è un vero applicativo 32 bit e gira tranquillamente sotto Windows da 2000 in poi. Fammi sapere se ti occorrono altre info. Ah, c’è anche un sito che si chiama proprio vivaclipper, e naturalmente il vecchio sito oasis dedicato a Clipper, mantenuto in vita da appassionati. Clipper insomma nella sua attuale reincarnazione è vivo e vegeto, e più potente e versatile che mai.
A rileggerci.
Salve,
“Clipper è un compilatore a 16 bit e genera applicativi a 16 bit, che non girano su Windows XP il quale è un sistema a 32 bit”
Contesto solo questa affermazione perché gli applicativi Clipper possono girare sui sistemi a 32 bit sia di Windows Xp, Windows 7 e Windows 8.
Per il resto un ottimo articolo che mi ha fatto rivivere quei periodi. Bravo! )
Grazie per la precisazione.
Ciò che dici è corretto, probabilmente quando scrivevo stavo pensando ai sistemi a 64 bit, invece mi è scappato 32. Certo che qualche problema c’era, comunque.
Mi piacerebbe anzi scrivere un articolo sui problemi nell’esecuzione di programmi Clipper in ambiente multitasking, è stato un mezzo incubo che ho vissuto in prima persona e me lo ricordo benissimo.
Quindi… davvero un lapsus bizzarro!
E grazie anche per l’apprezzamento