Showing posts with label Visual Objects. Show all posts
Showing posts with label Visual Objects. Show all posts

Wednesday, March 4, 2009

Is Visual Objects a 32/64 bits Compiler ? [Updated 10th March 2009]

I started this thread at comp.lang.clipper.visual-objects

Response by Brian Feldman, Product Owner, Visual Objects & Vulcan.net

CCH,

>>Have Grafx announced any plan for a 64-bits version ?

None. No 64 bit version of VO will be forth coming.

Most of our development efforts are focused on Vulcan.Net, and VO
maintenance.

Vulcan.NET, which is an xBase compiler for .NET based on the "Visual Objects language".

Vulcan.NET produces a .NET exe or .dll. Supports all MS Frameworks. It uses Microsoft Visual Studio 2005 or 2008 as an IDE. An alternative IDE has also been written in Vulcan.NET called VIDE and a trial version is also available for download at the website.

Simply put Vulcan.NET _IS_ xBase for the future.

More info at and free Trial Version at http://www.GoVulcan.NET

A good place to start is to download our 150 page getting started guide:
http://www.govulcan.net/portal/GettingStarted/tabid/59/Default.aspx

Brian Feldman
GrafX Software http://www.Grafxsoft.com

Product Owner Visual Objects
Product Owner Vulcan.NET

Comments by Erik & Geof Schaller on same thread as follows :-

1. Vulcan.NET produces a .NET exe or .dll. Supports all MS Frameworks.

The support of the CF is very limited.
With some fiddling you will be able to compile and run an app for the CF,
but you won't have DBF support, no Macrocompiler and also the VO compatible
classlibs will not work on the CF. Also the Vulcan-VS support for CF lacks
interesting features for the CF.

If you consider developing for the CF, you better use one of the MS
languages.

Same suggestion for any new development. C# is not that hard at all!

Erik

2. Geoff Schaller
Chee,

As Brian has indicated, there will never be a 64 bit version of VO.
However, any VO or Vulcan app will run perfectly in a 32 or 64 bit
environment so why should it matter? There is very little you would
"need" a 64 bit application for, other than to squeeze a few
milliseconds of performance out, but unless your application needs to
deal routinely with numbers > 4GB I would suggest that 64 bit is largely
irrelevant.

And if you need to work with huge numbers routinely, why not go to C# or
VB.net?

Geoff


Monday, February 23, 2009

Xbase++ vs Harbours: Clarifications on Multi-threading by Steffen F. Pirsig

Sorry to use your blog to comment on the comments of others, as I think this is not the idea of a blog. Anyway please allow me to clarify my statement. I said "clean and easy to use way of multithreading", i didn’t say the Harbours don’t support Multithreading. My statement is still true, even so Harbour and xHarbour have implemented the ability to execute code in multiple threads and have implemented some of the interfaces Xbase++ provides in one way or another. They are still far away from the idea and concepts of Xbase++ in that area. In addition Harbour and xHarbour implemented different semantics of isolation. Which makes porting of complex MT applications for sure a mess. Let me clarify that.

Multithreading as the ability to execute code in different code paths is a feature of modern OS sinces decades. The problem with MT is that it adds another dimension of complexity to the developers task. While with single threaded apps. the developer needs only to think in a more or less sequential way with MT each execution path adds a new dimentions to the equation of programm complexity. Development languages supporting MT such as Delphi, .NET (C#,VB) or Harbour and xHarbour support MT thats correct, but they do not remove the burden of correctness from the programmer. It is in the sole responsibility of the programmer to ensure programm correctness in two different areas; data-consistency and algorithm isolation.

The problem of data consistency occurs as soon as more than one thread is accessing the same data - such as a simple string or an array. Besides nuances in terms of single or multiple readers/writers the consistency of the data must be ensured, so developers are forced to use mutex-semaphores or other higher level concepts such monitors, guards... to ensure data-consistency.

Algorithm isolation is somewhat related to data-consistency, it becomes obvious that a linked-list accessed from multiple threads must be protected otherwise dangling pointer occurs. But what about a table/relation of a database. The problem here is that concurrency inside the process can be resolved - but this type of "isolation" does break the semantics of the isolation principles which are already provided by the underlying dbms (sql-isolation-levels, record or file locks, transactions). Therefore algorithm isolation/correctness is a complete different beast as it is located at a very high semantic level of the task.

Alaska Software has put an enormous amount of research efforts into that area and we have more than a decade of practical experience with that area based on real world customers and real world applications. From that point of view I would like to reiterate my initial statement "As of today there is still no tool available in the market which provides that clean and easy to use way of multithreading".

Lets start with xHarbour, its MT implementation is not well thought, as it provides MT features to the programmer without any model, just the features. xHarbour even allows the usage of a workarea from different threads which is a violation of fundamental dbms isolation principles. In fact xHarbour ist just a system language in the sense of MT and makes life not really easier compared with other system languages. Therefore there is no value in besides being able to do MT. Also keep in mind due to the historical burden of the VM and RT core the MT feature is implemented in a way making it impossible to scale in future multi-core scenarios (see later-note).

Harbour is better here because if follows more the principles of Xbase++, while I am not sure if the Harbour people have decided to adapt the Xbase++ model for compatibility reasons or not I am glad to see that they followed our models point of view. The issues with Harbour however is that it suffers from the shortcoming of its runtime in general, the VM design and of course the way how datatypes - the blood of a language - are handled. It is still in a 1980 architectual style centered around the original concept how Clipper did it. This is also true for xHarbour, so both suffer from the fact that MT was added I think in 2007, while the VM and RT core is from 1999 - without having MT in mind.

This is in fact one of the biggest differences between
Xbase++ and the "Harbours" from a pure architectual point of view, we designed a runtime architecture from the beginning to be MT/MP and Distributed, they designed a runtime based on the DOS Clipper blueprint.

In fact, I could argue on and on, specifically it it comes to dedicated implementations of the Harbour runtime core or the Harbour VM but sharing these type of technical details is of course definitively not what I am paid for -;) Anyway allow me to make it clear in a general terms.

First, any feature/functionality of Xbase++ is reentrant there is not a single exception of this rule. Second, any datatype and storage type is thread-safe regardless of its complexity so there is no way to crash an Xbase++ process using multithreading. Third, the runtime guarantees that there is no possibility of a deadlock in terms of its internal state regardless what you are doing in different threads. There is a clean isolation and inheritance relationship of settings between different threads. In practical terms that means, you can output to the console from different threads without any additional code, you can execute methods or access state of GUI (XbasePARTS) objects from different threads, you can create a codeblock which detaches a local variable and pass it to another thread, you are performing file I/O or executing a remote procedure call and in the meanwhile the async. garbagge collector cleans up your memory - and the list goes on... But in Xbase++ you can do all that without the need to think about MT or ask a question such as "Is the ASort() function thread safe" or can I change the caption of a GUI control from another thread. Thats all a given, no restrictions apply, the runtime does it all automatically for you.

Anyway, I like Harbour more than xHarbour in terms of MT support. However the crux is still there, no real architecture around the product, leading to the fact that MT is supported form a technical point of view but not from a 4GL therefore leading to a potential of unnecessary burden for the average programmers, and of course that was and is still not the idea of Clipper as a tool.

Btw, the same is true for VO or so, they left the idea of the language and moved to something more like a system -language, while I can understand that somewhat I strongly disagree with that type of language design for a simple reasons; its not practical in the long term - we will see that in the following years as more and more multi core system will find their way in the mainstream and developers need to make use of them for performance and scaleability reasons. In 10 - 15 years from now we will have 100 if not thousands cores per die - handling multithreading , synchronisation issues by hand becomes then impossible, the same is true for offloading tasks for performance reasons. So there is a need for a clean model in terms of the language - thats at least into what we believe at Alaska Software. It goes even further, the current attempty by MS in terms of multicore support with VS2010 or NET 4.0 are IMO absolutely wrong, as they force the developer to write code depending on the underlaying execution infrastructure alias cores available. In other words, infrastructure related code/algorithms get mixed with the original algorithm the developers writes and of course the developer gets payed for. Thats a catastrophic path which for sure does not contribute to increased productivity and reliability of software solutions.

Funnily enough, the most critical, and most difficult aspect in that area; getting performance gains from multi core usage is even not touched with my technical arguments right now. However it adds another dimension of complexity to the previous equation as it needs to take into account the memory hierarchy which must be handled by a 4GL runtime totally different as it is with the simple approach of Harbour/xHarbour. Their RT core and VM needs a more or less complete rewrite and redesign to go that path.

In other words, Xbase++ is playing in the Multithreading ballpark since a decade. Harbour is still finding its way into the MT ballpark while xHarbour is in that context at a dead-end.

I would bet that Xbase++ will play in the multicore ballpack while the Harbours are still with their MT stuff.

In a more theoretical sense, it is important to understand that a programming language and its infrastructure shall not adapt any technical feature, requirement or hype. Because then the language and infrastucture are getting more and more complicated up to an point of lost control. Also backward compatibility and therefore protection of existing investments becomes more and more a mess with Q&A costs going through the roof.

Nor is it a good idea to provide software developers any freedom - the point here is, a good MT modell does smoothly guide the developer through the hurdels and most of the time is even not in the awareness of the developer. The contrary is providing the developer all freedom, but this leads to letting him first build the gun-powder, then the gun to finally shoot a bullet -;)

Therefore let me rephrase my initial statement to be more specific;

As of today there is still no tool available in the market which provides that clean and easy to use way of multithreading, however there are other tools which support MT - but they support it just as an technical feature without a modell and thats simple wrong as it leads to additional dimensions in code complexity - finally ending in applications with lesser reliability and overall quality.

Just my point of view on that subject - enough said

Steffen F. Pirsig

Sunday, February 22, 2009

Harbour Does Support Multi-threading - Pritpal Bedi - 2009-02-22

CCH: on 22 February 2008, Pritpal Bedi, Harbour Developer posted an interesting entry in our Guest Book, which amongst other things clearly rebutted Xbase++ CTO, Steffen's assertion on 21 February 2009 that "As of today there is still no tool available in the market which provides that clean and easy to use way of multithreading"

He also documented his journey from CA-Clipper, CA-Visual Objects, Xbase++, xHarbour and finally to the Harbour Project.

Pritpal Bedi, 22nd February 2009

Hello Chee

Nice to see such an informative site to have upto-date information about trends and developments centering around language called "CLIPPER".

Developing mini-erp solutions for trade and indistry in general and for specific verticals, in Clipper, for over a decade, I recently have discontinued support for Clipper compilations for ever. Today all my applications are compiled with Harbour ( also with xHarbour for some specific purposes ) with a unique look and feel simulating Windows GUI.

In late 90s the demand for a visual uplift was more an more coming in,
Visual Object caught my attention and I tried my hands onto that. Alas! I failed miserably. Visual Obects was enforcing a new way of programming concept difficult to be accepted by one who has had invested a great amount of time and money on developing procedural code. More so, the procedural code was delivering what was expected. So I gave up after few months of frusration.

Then came
Xbase++, probably in 1998, and then I was filled with joy that this is exactly I wanted. Straight forward I subscribed to it, and continue to subscibe till date, though do not plan in the future. After few months I could convert my applications running on Xbase++. I was amused by the multi-threading modal and its capabilities to mix GUI and CUI elements on one screen. It paved the way for Clipper code to be migrated to Windows world. I was/is a dire fan of its XbpParts* class modal which implemented a standard way of objecthirarchy and parameters. I also put my applications in production sites but due to many technical difficulties I had to withdraw them and reinstalled Clipper compilations. I agree that those were the days when Xbase++ was evolving. I could hae concentrated on Xbase++ IF I could not came face-to-face with xHarbour...

My first attempts with
xHarbour were so rewarding that I could develop VOUCH32 library which could be used with Xbase++, xHarbour, Clipper ( not Harbour ). It proved to be very useful addon atleast for Clipper applns ( download statistics suggest that ). A journey started to port 16 bit code to 32 bits which was accomplished with little effort. But still everything was under debugging in the labs. An awesome contribution from Peter Rees ( GTWVT ) in Dec 2002 triggered my quest to provide Windows look and feel to my CUI applns. I could develop WVTGUI which gave my applns a new lease of life. I posted new technology to my clients by end 2003 which received a wide acclaim.

The journey continued. Though I could simulate Windows look and feel, but still I heavily missed multi-threading and multiple Windows support of Xbase++. Something I missed all those years.

In 2007 I turned to
Harbour. Ported all what I had contibuted to xHarbour and recompiled my applns. There I floated ideas of Multi-Threading and Multi-Windows which got momentum as I showed to the group its real benefits. Przemyslaw Czerpak, this great programmer, took to this challenge and introduced both concepts in a superb manner. I insisted on Xbase++ modal of Multi-threading minus its glitches which were taken care of in proper perspective. And the result is a robust MT modal which also implements Xbase++ functions and objects.

Recently I posted all my applications in production with Multi-theading and Multi-Windows, with a unique Windows look and feel and functionality, the source base being the same I used to compile with CLIPPER, just with addition ( not changes ) of few lines of code. CLIPPER is ALIVE as ever...

As Harbour and xHarbour are binary compitble projects, every development can be shared by both projects.

Somewhere on this blog I have read Steffens quote ;
"As of today there is still no tool available in the market which provides that clean and easy to use way of multithreading."

This is not true. Harbour is much more robust. But mind it, Xbase++ provided it in 1998 whereas Harbour implemented it in 2008, a generation-gap.

I must admit that at present Harbour ( in its core ) lacks a GUI component, a must for modern day requirements. To achieve this goal I have initiated development of WVG*Parts along the lines of Xbase++ Xbp*Parts, which by now, is shaping up well. It follows the Xbase++ class modal exactly it is documented. By now a simple Xbase++ application can be ported to Harbour with restricted GUI components, AS IS. Harbour may have a decent GUI in near future, who knows...

To sum-up I must say that the language "CLIPPER" we all loved most, we all earned our bread and butter for decaded, we all sweared-by, is
VERY MUCH ALIVE ...

Regards
Pritpal Bedi
a student of software analysis & design


Born 04 June 1956 at a small town Karnal, a part of the then Punjab province
of the Sovereign Republic of India, attracted to software development only in
1989 at the age of 33 years. Authored VOUCH, the software grows with you,
a mini ERP solution based on Indian way of business protocols. Attracted to
xHarbour in 2002 and soon contributed to the Clipper community, Vouch32.lib.

Also he contributed to the open-source project xHarbour whatever small
he could do, major contribution being WVTGUI, a library to give a look and
feel of Windows application to a character based console application. This
he could do on the top of GTWVT, a contribution by Peter Rees.

And now, he presents Vouch32 ActiveX Server raising the barrier of languages
and version control. A Com Object completely written in xHarbour and
compiled with xHarbour.com distribution.

Author is a Master degree holder in Commerce. Has served the banking industry,
has run a medium-scale retail business, and has achieved a little in
software development.

Saturday, February 21, 2009

What is CA-Visual Objects ?

CCH : CA-VO aka CA-Visual Objects was Computer Associates attempt to bring CA-Clipper to the Windows World.

BTW, in my quest to move into the Windows world, I actually bought a copy way back in 1995 and attended a 5-day Training by the renowned Clipper Guru, Rick Spence in Kuala Lumpur, Malaysia. That was before I discovered Delphi.

As I understand it, CA-VO development was taken over by GrafX Software Development and the latest version is 2.8 released on 15th May 2007


From http://www.ca-vo.com

Clipper Compatibility


Visual Objects features a structured superset of the Clipper Language. While the user interface will need to be redesigned to take advantage of the Windows Graphical User Interface (GUI), most of the core "business logic" used in Clipper applications can be recomplied as-is under Visual Objects.

Visual Objects includes support for Clipper based DBF files including those using the NTX, CDX, and MDX indexing methods via Replaceable Database Driver (RDD) technology.


Xbase Superset


Visual Objects features a structured superset of the Xbase language. (Xbase is the industry standard term for those programming languages that inherit from the original dBASE system, including CA-Clipper, CA-dBFast, the dBASE family of products, and FoxPro.)

The Xbase superset contains extensions for Windows and its environment, including the ability to access all Win32 Application Programming Interface (API) functions for low-level, system programming.

Open Database Access

Visual Objects gives you a wide variety of choices in terms of database access. It supports:
  • Both procedural and object-oriented access to Xbase databases

    Visual Objects supports the procedural database commands and functions—such as SKIP and EOF()—that are traditional to Xbase languages.

    It also includes, however, an object-oriented interface to Xbase database management. The object-oriented interface is akin, semantically and syntactically, to the commands and functions traditionally used in procedural access. Instead of commands like APPEND, COMMIT, and ZAP, for example, you will use methods named Append(), Commit(), and Zap() to perform the same operation.

    Note: With these new methods, all the capabilities of the traditional Xbase approach are provided, but have been enhanced to fit the event-driven, multi-tasking nature of GUI applications.

  • Access to both Xbase and SQL databases

    When using an object-oriented approach to database management, both Xbase and SQL databases can be accessed. Furthermore, access to these two different types of databases is accomplished using a single, compatible protocol. This allows an application to manage Xbase and SQL databases with the same code.

  • Several different Xbase/SQL database formats

    When accessing Xbase databases (using either a procedural or object-oriented approach), you can choose from a variety of file formats. This is accomplished through replaceable database driver (RDD) technology. With RDDs, a single application can access different database file formats using a common language interface. This allows you to tailor your applications so that migrating from one database format to another is simple and straightforward.

    Visual Objects supplies several popular RDDs, and through its open architecture allows for development of third-party RDDs. See the Replaceable Database Drivers section in the “Using DBF Files” chapter in the Programmer’s Guide for more information about RDD technology. Refer to the “RDD Specifics” appendix in the same volume for detailed information about specific RDDs.

    Similarly, support for SQL databases is accomplished using Open Database Connectivity (ODBC), a widely used API for SQL access under Windows. This technology also uses replaceable drivers, supplied as dynamic link libraries (DLLs), which standardize the interface to the various database formats. Visual Objects comes bundled with DLLs for many of the popular ODBC formats, and provides language support for a superset of the standard ODBC API, as well as, an object-oriented interface compatible with that used for Xbase database files.

Sunday, February 15, 2009

CA-Clipper is Alive & Well

I am simply amazed that the Clipper Language (in the form of CA-Clipper, Xbase++, Harbour, xHarbour & CA-Visual Objects) is still being used by Clipperheads from over 73 countries since 26th January 2009, latest from Pakistan , Dominican Republic, Kenya, China, South Africa Bosnia & Herzegovina, Uruguay, Turkey, Guam(23/2/09) , Paraguay(23/2/09), Iceland ,South Korea (24/2/09), Israel , Bulgaria, Taiwan (25/2/09), Denmark (27/2/08), Estonia(28/2/08)

Looking at the statistics...

a) 28 January 2008 (Day 3), 20 countries such as Germany, Canada, Belarus, Italy, USA, Spain, Philippines, Netherlands, South Africa, Austria, United Kingdom, Croatia, Ireland, Norway, Switzerland, Serbia, Poland, Australia, Indonesia , Malaysia,

b) 1st February 2009 (Day 3), 10 new countries making up a total of 30 countries including France, Ukraine, Latvia, Greece, Ireland, Spain, Portugal, Romania, Argentina, Mexico, Austria & Venezuela

As at 23rd February 2009, we now have Clipperheads from :-

Europe
  1. Austria (3/9, 4), Steiermarch, Wien (Vienna) , Tirol(Sillian, ), Saltzburg
  2. Belarus(4,4), Vitsyebskaya Voblasts(Vitebsk), Minsk,Homyel'skaya Voblasts'(Gomel)
  3. Belgium (6/10,11), Antwerpen(Antwerp, Mol, Grobbendonk, Schoten,Mechelen), Brabant(Sint-genesius-rode), Liege, West-vlaanderen(Avelgem,Damme), Oost-vlaanderen (Zottegem), Hainaut(Charleroi)
  4. Bosnia-Herzigovina(1,1), Mostar
  5. Bulgaria(2,2), Pleven(Levski), Varna
  6. Croatia(1,2), Grad Zagreb (Zagreb,Samobor)
  7. Cyprus(1,1), Nicosia
  8. Czech Republic(3/13,3), Moravskoslezsky Kraj, Stredocesky Kraj(Mlada Boleslav),Hlavni Mestro Praha(Praque)
  9. Denmark(1,1), Staden Kobenhavn(Copenhagen)
  10. Estonia, Harjumaa(Tallinn)
  11. Finland(1,1), Southern Finland(Helsinki)
  12. France (7/26,7) from Languedoc-roussillon, Rhone-alpes(Baix), Sorel-moussel , Aquitaine(Bordeaux), Centre(Saint Aignan), Midi-pyrenees(Albi), Ile-de-france(Paris)
  13. German (14/16,32), Berlin, Baden-Wurttemberg(Asperg, Oftersheim, Mannheim,Stuttgart), Bayern(Elsendorf,Neufahrn,Röthlein, Hirschaid,Bad Tölz,Sonthofen), Frankfurt Am Main, Hamburg, Hessen(Bad Vivel, Rosbach, Friedrichsdorf, Wiesbaden, Kronberg,Griesheim), Niedersachsen(Achim, Edemissen,Moisburg) , Nordrhein-westfalen (Bielefeld,Essen,Wuppertal), Mecklenburg-vorpommern(Bergen), Rheinland-pfalz, Schleswig-holstein(Roseburg), Sachsen-anhalt(Wolfen,Magdeburg), Sachsen(Dresden), Thuringen(Efurt)
  14. Greece(2,2), Attiki(Athens) , Thessalonki, Xanthi(Xánthi)
  15. Hungary(5,5), Budapest, Debrecen, Fejer(Székesfehérvár),Somogy(Kaposvár), Bekes(Békéscsaba)
  16. Iceland(1,1), Gullbringusysla(Reykjavík)
  17. Ireland(1)
  18. Italy (14/20,27), Toscana(Pisa Prato), Lazio (Rome) , Liguria (Genoa), Lombardia(Brescia, Milan, Marcallo Con Casone,Vimodrone), Piemonte(Desana,Novara,Moncalieri, Verceli,Cuorgnè), Puglia(Bari), Friuli-venezia Giulia(Monfalcone), Trentino-alto Adige (Adige, Trento,Bolzano), Sicilia(Misterbianco), Emila-romagna (Bologna, Imola, Modena,Forlì), Sardegna(Quartucciu,Cagliari), Veneto(Verona,Padova), Campania(Naples,San Giorgio A Cremano), Veneto(Padova)
  19. Latvia(1,1), Riga
  20. Lithuania(1,1), Kauno Apskritis
  21. Luxembourg(1), Diekirch(Erpeldange)
  22. Macedonia(1)
  23. Moldava(1)
  24. Netherlands (8,12), Noord-holland(Bussum), Noord-brabant(Eindhoven,Prinsenbeek), Flevoland, Utrecht(Wijk Bij Duurstede, Bilthoven, Amerongen), Groningen(Usquert), Limburg(Tegelen), Gelderland(Epe,Nijmegen ), Zuid-holland(Rijswijk)
  25. Norway(1)
  26. Poland (16,20), Kielce, Bielsko, Gdansk(Gdynia), Warszawa (Warsaw, Pruszków,Blonie), Ciechanow, Biala Podlaska, Bielsko (Oswiecim), Wielkopolskie(Poznan), Walbrzych (Nowa Ruda),Walbrzych (Nowa Ruda), Poznan (Grodzisk, Wielkopolski),Katowice(Ledziny), Torun, Dolnoslaskie(Wroclaw),Radom,Slaskie(Katowice), Lodzkie(Lodz), Radom,
  27. Portugal(4,4), Porto, Lisboa(Lisbon), Braga (Santa Maria), Faro (Santa Bárbara De Nexe)
  28. Romania(2,2), Brasov,Iasi,Vaslui, Bistrita-nasaud(Vatra Dornei)
  29. Russian Federation(5,5), Moscow(Moscow City), Primor'ye(Vladivostok),Kaluga, Saratov, Yaroslavl'(Yaroslavl)
  30. Serbia(1, 3), Serbia Proper(Belgrade, Kragujevac,Dardania)
  31. Slovakia(1) Bratislava
  32. Slovenia(1,5), Bohinj(Kranj,Sempeter,Ljubljana,Sempeter,Trzin,Novo Mesto)
  33. Spain (12,15), Casti-la Moncha, Islas Baleares, Catalonia (Barcelona,Gerona,Salt), Murcia (Alcantarilla) , Andalucia(Málaga,Dos Hermanas), Madrid(Villaviciosa De Odón), Extremadura, Galicia(Lalín,Santiago De Compostela), Pais Vasco(Irún), Castilla Y Leon(Burgos), Navarra (Tafalla), Canarias(Las Palmas)
  34. Sweden(2,2), Norrbottens Lan(Luleå), Stockholms Lan (Södertälje,)
  35. Switzerland(2,2), Berne, Schaffhausen
  36. Turkey(3,3), Hatay, Istanbul, Ankara
  37. United Kingdom(12,12), from London, Glasglow(Glasgow City), Derbyshire(Derby), Gloucestershire(Gloucester), Rochdal, New Hampshire(Manchester), West Sussex(Pagham), Devon(Barnstaple), Leicestershire(Hinckley)
    Cambridgeshire(Cambridge),Cheshire(Winsford), Kirklees(Huddersfield)
  38. Ukraine(7,7), Kyyivs'ka Oblast (Kiev), Mykolayivs'ka Oblast' (Nikolaev), Kharkivs'ka Oblast' (Kharkov), Odes'ka Oblast(Odessa), Zaporiz'ka Oblast(Zaporozhye), Zaporiz'ka Oblast' (Zaporozhye), Donets'ka Oblast'(Malaya)

African & Middle-East
  1. Democratic Republic of Congo(1,1), Kinshasa
  2. South Africa(3,3), Gauteng(Johannesburg),Western Cape(Cape Town), North-west(Fochville), Kwazulu-natal(Durban)
  3. Egypt(2,2), Cairo, Al Qahirah(Helwan)
  4. Israel(1,1), Hamerkaz(Rishon Le Zion)
  5. Kenya(1,1), Nairobi Area (Nairobi,)
  6. Morocco(1)
  7. Nigeria(1,1), Federal Capital Territory(Abuja)
  8. Saudi Arabia(1,1)
  9. UAE(1,1), Sharjah

North America
Canada (7/13,12)
  1. Alberta (Edmonton)
  2. Manitoba
  3. New Brunswick
  4. Ontario (Cobourg,Toronto,Etobicoke, Barrie)
  5. Quebec (Montreal,Verdun,Rimouski)
  6. Saskatchewan(Saskatoon)
  7. British Columbia(Sidney)

USA (30/64)
  1. Alabama (Birmingham, Harvest)
  2. Arizona (Chinle)
  3. California (Brea, Cathedral City, Los Angeles, Sacremento,Oakland,Vacaville, Merced,Rowland Heights,Long Beach)
  4. Colorado, Colorado Springs
  5. Connecticut(Hamden)
  6. Idaho (Meridian)
  7. Illinois (Alsip, Orland Park)
  8. Florida (Saint Cloud,West Palm Beach, Miami,Tallahassee, Orange Park,Jacksonville)
  9. Georgia (Alpharetta, Savannah, Tampa,Marietta,Atlanta)
  10. Kansas
  11. Louisiana,Monroe,
  12. Maine
  13. Massachusetts(Tewksbury, Bedford)
  14. Michigan
  15. Missouri
  16. New Jersey(Teaneck)
  17. New York (Astoria, Brookyln, West Islip,Rego Park,Flushing)
  18. North Carolina (Mooresville)
  19. Ohio (Powell,Hudson,Cincinnati,)
  20. Oklahoma (Oklahoma City)
  21. Oregon (Portland)
  22. Pennsylvania (Landsdale,West Chester,Doylestown)
  23. South Carolina (Florence)
  24. Tennessee
  25. Texas (Dallas, San Antonio, Houston)
  26. Virginia, Richmond
  27. West Virginia
  28. Washington (Seattle)
  29. Wisconsin (Appleton, Madison, Bellingham, Hatley,Wausau,Plover)
  30. Utah (Ogden, Salt Lake City)

Central America
Mexico(14,14)
  1. Jalisco (Zapopan)
  2. Distrito Federal(Mexico)
  3. Naucalpan
  4. Guanajuato(León)
  5. Morelos
  6. Sonora (Obregon)
  7. Guerrero(Chilpancingo)
  8. Chiapas(Tuxtla Gutiérrez)
  9. Veracruz-llave(Veracruz)
  10. Guerrero(Chilpancingo)
  11. Quintana Roo(Chetumal)
  12. Juarez
  13. Tamaulipas(Tampico)
  14. Tabasco(Villahermosa)

South America
  1. Argentina(10/25), Bueno Aires(Bahia Blanca,Bernal, Brandsen, Boulogne,Berazategui, Distrito Federal, Matheu, Lanús,La Plata, Monte Grande, Quilmes,Villa Ballester), Cordoba(Córdoba, Laboulaye, Serrano), Mendoza(Junín), Santa Fe(Rosario,Villa Constitución), Chaco(Resistencia), Neuquen(Neuquén), Mendoza (Rivadavia), Neuquen(San Martín De Los Andes),Entre Rios(Concordia), Mendoza
  2. Brazil (9/15), Bahia (Salvador) , Sao Polo(Avaré, Itapira,São Paulo,Rio Claro), Parana(Campo Mourão,Curitiba,Londrina,, Pernambuco(Recife,Olinda,), Minas Gerais, Santa Catarina(Schroeder), Goias(Goiânia),Paraiba(Patos), Distrito Federal(Brasília)
  3. Chile(2), Region Metropolitana (Santiago),Magallanes Y De La Antartica Chilena(Punta Arenas), Coquimbo, Bio-bio(Chillán)
  4. Colombia(4), Atlantico (Barranquilla),Santander(Bucaramanga), Department(Tunja, Boyacá), Cundinamarca(Bogotá)
  5. Dominician Republic (Santiago)
  6. Ecuador, Pichinca (Quito)
  7. Paraguay, Asuncion
  8. Peru(2), Piura(Sullana), Lima
  9. Uruguay, Montevideo
  10. Venezuela(8), Nueva Esparta(Manzanillo), Distrito Federal (Caracas), Bolivar, Monagas, Aragua(Maracay), Anzoategui(Barcelona), Barinas, Anzoategu(Barcelona)

Asia-Pacific
  1. Australia(4/8, 5), Queensland(Brisbane), New South Wales (Sydney,Murwillumbah), Victoria (Box Hill, Melbourne) & Western Australia(Perth)
  2. China(2,2) , Guangdong(Guangzhou), Guangxi (Nanning)
  3. Guam(1)
  4. Hong Kong(1), Quarry Bay,Central District
  5. India (7/35,8), Maharasta(Bombay,Pune) , Kerala (Kochi), Gujarat(Surat,Ahmadabad), Karnataka(Bangalore), Tamil Nadu(Madras), West Bengal(Calcutta) & Delhi (New Delhi)
  6. Indonesia(1,1), Jakarta Raya (Jakarta)
  7. Malaysia (6/13,8) , Penang, Kelantan(Pasir Mas), Selangor(Shah Alam, Petaling Jaya), Johor, Sabah(Kota Kinabalu), Sarawak (Kuching), Melaka
  8. New Zealand(1), Wellington(Porirua)
  9. Pakistan(2,2), Punjab(Sahiwal), Kashmir
  10. Philippines(3,4), Cebu City, Manila,Rizal(Malanday,Parañaque),Davao(Tagum, )
  11. Singapore(1)
  12. South Korea(1), Seoul-t'ukpyolsi (Seoul)
  13. Taiwan, T'ai-pei(Taipei)
  14. Thailand(2), Khan Kaen, Krung Thep (Bangkok)

Monday, January 26, 2009

Clipper on life support ? [28th July 1996]

"Clipper on life support ?- Steve Silverwood's posting of CA's contemplating dropping CA-Clipper development..."

Hi to all Clipperheads,

Steve's posting seems alarming in the sense that CA has indicated on Compuserve that they may drop further Clipper development .

I am the developer of the KarenSoft range of Clipper vertical applications for a wide range of business applications. Visit http://www.cch.com.my/cch/cchss to see what you can actually develop using 5.2e.

As such, I use 5.2e to earn a living and I have not found anything that could not be done with it ! If there is a function that I require which is not available withing Clipper, I'll :

a) write one - beauty of Clippers' UDF concept b) buy a third part product (ok ! is you don't use 5.3) c) look at NANFOR.LIB d) pick up a freeware or shareware on Phil Barnett's OASIS FTP or from any of the fine Clippper WWW sites

What about Clipper for Windows ?

With cheap Pentium PCs with 16MB on board, we can no longer ignore Windows & Windows NT. As a professional software developer, I have looked at virtually all the Windows development tools available to the Clipper developer and have settled for FiveWin+5.2e. Unfortunately, I did not get a chance to use Clip4Win as I found what I wanted with FiveWin. BTW, I actually bought Clip4Win and I intend to look at it one day as there are Clipper developers that swear by it...

Trouble is 5.2e+FiveWin produces 16 bit apps... Currently, I don't see any problems but with the growing popularity of Windows NT, the market may begin to demand for 32 bit apps. With no 32bit Clipper, I don't see a 32bit FiveWin..

So what's the choices for 32 bit development tools ?

VO 2.0 - going to public beta soon... and Delphi 2.0 for 32 bits Windows is already available. No comments for VO 2.0 althought it appears to be promising on paper. I have looked at Delphi 2 and it looks very promising though it is pascal based. BTW there are a couple of 3rd party components like Appollo & Infopower that makes it clipper like. That's what the ZAC catalog say..

Conclusion :

Even if CA decides to stop developing Clipper, I'll continue using 5.2e for DOS apps as I have yet to use it to its fullest potential. Moreover, I believe that the numerous non-commercial WWW Clipper sites, including mine and especially Phil Barnett's OASIS will help to keep it alive. So long as there is demand for DOS based applications, Clipper will remain as the premier DOS development language.

As for Windows, I'll continue to use 5.2e+FiveWin for 16 bits Windows apps while I'll look at Delphi 2.0 for 32 bit development.

So is Clipper dead ?

Regards

Chee Chong Hwa

Back to the Future by Roger Donnay [14 July 1996]

This thought provoking article by Roger Donnay, the author of dCLIP(tm) was originally posted on comp.lang.clipper by Andi Jahja of Indonesia. To make it more interesting, I have also added Terry Carmen's rebuttal of certain sections also posted on 29 June 1996. Just received an e-mail on 13th July 1996 from Roger giving his consent to publish this article.

Back to the Future by Roger Donnay


BACK TO THE FUTURE

Like all other forward thinking programmers, I have been watching the horizon anxiously for the last several years. While staying firmly in the Clipper arena, I've done work in Windows via products like VO and VB and have played around with FoxPro and dBase for Windows. But my vision has been foggy. For the first time in many years, I've been groping for my direction. I've noticed that we've all been eyeing each other for clues. The leaders have been following. Microsoft seems to hold our future in its hands. We are bleeting like sheep. But I recently saw beneath the sheepskins. We are not followers! We have been hit in the back of the head with a big stick and sheepskins have been thrown over us. We're in a state of amnesia. It is inevitable that we will "come to" and remember wer'e not prey after all. Before our collective coma, programmers were the leaders, the discoverers, the thought pioneers. We must shake off our myopia quickly lest we all be led to slaughter. To regain our vision and perspective, we must step back and see the larger human picture, not just the technical parts we've been focusing on. This bigger picture presented itself to me recently at the 1995 CGDN Clipper/VO Conference in The Netherlands. On the last day of the conference, I was asked, in a panel discussion, to comment on the future of software development. The other panelists made predictions that included statements about Windows, SQL, OLE-2, multi-media, OOPS, and basically a universe that will have little or no resemblance to that in which most systems developers make their living today. I was fascinated by the technical nature of the panelists predictions and how they described this new world in detail as though it were a well-understood fact that it had to evolve by some pre-written script. It reminded me of the Popular Science magazines I used to read as a teenager. I recall reading how the world would automatically adapt to and accept all modern technology. There would be no resistance to change because those who promoted change did so for our own good with the goal of creating a better world for all mankind. Basically, the message we received was this:

"We'll build more factories with the latest robotic technology, put our unemployed to work, which will allow us to increase the goods and services in our economy and our money supply so we can pay higher wages and have more money for scientific research. We'll focus on creating new robotic technology so we can free up workers to do other things, like space technology research, and mining the asteroid belt so we can create spaceships that move faster than the speed of light to mine the universe. We'll invent a matter transformation machine so we can have unlimited resources without leaving the planet. Factories will be totally run by machines. Everyone will be guaranteed a job. Minimum wage will be 100 thousand dollars a year. College and Health Care will be free. We'll have unlimited money for education, college will be more user friendly, and if you can understand how an engine works you can be a physicist. Eventually, we'll colonize the universe and our new will make disease and death obsolete."

Many of us who believed the above predictions also believed that these changes would occur within our own life-time. As I listened to each person on the discussion panel, I was starting to realize that what was being described was a changing software and information universe that mirrored the above predictions for our changing physical and social universe:

"We'll build an information highway with the latest computer, software and communications technology, which will put our unemployed to work and allow us to increase the number of computers and logged on users. We'll focus on creating libraries of common sub-system objects to free up programmers to do other things like designing desktops and reports. We'll create a single standard for common user interface, a common language and a common protocol to make it possible for every single human being to be "computer-literate". No one will need to go to school to learn how to use the new computers. College will become obsolete. All the knowledge in the universe will exist on the information superhighway and access to this information will be faster than the speed of light. Anyone who understands how to use Windows will be guaranteed a job as a programmer. Eventually, we'll colonize the human mind and our new information system will make human error obsolete because the operating system will guide us through the depths of cyberspace."

Will this new world be created and maintained by a small number of monopolistic giants who will continue to make the rules while software developers and users happily comply and adapt to the "new paradigm"?

Not likely.

Ok, now that I have vented my emotions and basically put myself at risk of being labeled as another "paranoid programmer", let's be a little more realistic and pragmatic and view this changing world in a way that will give us some tools to better handle the transition for ourselves and our customers.

A BODY IN MOTION

At the CDGN I made the following statement:

"Operating Systems and Languages have a tendency to hang on much longer than we think they will. I predict that there will be a Clipper 5.4, 5.5, and even 6.0."

I made this prediction because of what I know about the process of change. As an Electronics Engineer, I spent as many years developing hardware as I did developing software and became acutely aware of how easy it is to evolve technology when human interface and compatability is NOT involved and how hard it is to evolve technology when human interface or compatability IS involved. For example, the evolution of hard-disk technology, memory technology and integrated circuit technology has leaped forward year after year, whereas the basic computer display and keyboard are not much different than those I was designing back in the late 70's.

Those of us who were around when IBM first introduced the PC in 1981 were amazed at how fast CP/M died after MS-DOS was introduced. This "instant death" phenomena led many to believe that DOS would die just as quickly after the introduction of Windows. PC Magazine predicted the death of DOS in 1988 yet it is still going strong 7 years later. There are several reasons why CP/M died so quickly but probably the main reason was because MS-DOS was almost a clone of CP/M but written for a different processor that was being mass produced and could access 10 times the memory. MS-DOS was NOT a new paradigm. In fact, converting CP/M applications to DOS was so simple that it required simply purchasing a cross-assembler or cross-compiler to convert 8080 code to 8086 code.

After the release of Visual Objects, many Clipper product distributors were gearing up for the death of Clipper by replacing advertising space for their Clipper products and training with advertising space for new Visual Objects add-ons and training. What happened next was not what was expected. Not only were the distributors dissatisfied with the poor performance in sales of VO add-ons but they were surprised at how Clipper add-ons continued to sell at the same rate even though advertising space had diminished. What they failed to take into account was that there is a "momentum" in the Clipper world that cannot be simply shifted to the VO world. Maybe they thought that this momentum would gravitate to VO in the same way that the momentum in the dBASE-III world easily shifted to FoxPro. Well, in retrospect it is easy to see that FoxPro does everything as well or better than dBASE and with no required "paradigm shift", whereas VO cannot even handle the simplest of Clipper applications.

Clipper is a body that has been in motion for 10 years, and being DOS-based, also brings with it the collective weight of 70 million DOS users. This momentum is not only impossible to stop but very difficult to even slow down.

THE NEW PARADIGM

At one time or another, most system developers have been confronted with a new paradigm that requires they take a different view of their world. Assembler programmers were confronted with C, C programmers were confronted with C++, mainframe programmers were confronted with microcomputers, procedural programmers were confronted with OOPS and event-driven programming. Windows is a new paradigm that offers great new opportunities for some programmers, and great new obstacles to others. The key to success in adapting applications to the new paradigm is not only knowing "how" an application should be converted but also knowing "if" and "when" it should be converted.

Even though many new paradigms bring excitement and opportunity, they also are a paradox, because while being pulled by customers to support the new methods, the same customers will resist using the methods they were pleading for. Why? Because people have difficulty adapting to change. Systems developers are people too. I try to balance my view of the future by looking at the past and watching human behavior. It is very unlikely that humans will behave any differently in the next 100 years than they did in the past 100 years just as it is unlikely that software developers will behave much differently in the next 5 years than they did in the past 5 years. We will continue to have the same prejudices, religions, fears, political alliances, learning disabilities, and overall dysfunction that has always kept us from fulfilling our vision of the "perfect world".

One of my customers is struggling with trying to decide on a development strategy for the next 2 years. He has a very powerful, data-driven, Clipper application that has evolved for nearly ten years. His business is growing faster than ever and he has never lost a sale to a competing Windows product, yet he is being pushed and pulled to convert his application to Windows. He said to me the other day: "I hear that in 2 years all DOS applications will be converted to Windows." I asked him if there was anything his application could do under Windows that it can't do under DOS and his answer was the same answer I get from most developers. They all say that their customers are asking for the following features:

1. Want to navigate the application with a graphical mouse. 2. Want consistent pull-down menus and better dialogue screens. 3. Want to suspend operation at any time and call up a different program, or the same program in another window to perform different operations. 4. Want to minimize the application window to the desktop with the click of the mouse. 5. Want to move the application window to any position on the desktop with the mouse. 6. Want to run other Windows programs without needing to quit the application. 7. Want to run the application in the background to handle tasks like indexing files, backups, etc. 8. Want to navigate data-entry screens with the mouse. 9. Want to run the application in a Windows memory environment.

What many Clipper developers (and their customers) do not realize is that 5 of the 9 requests listed above are already supported by Windows 3.1 and OS/2 in their "Windowed DOS boxes". The other requests are simply a matter of adding mouse support and better menus to their existing applications and linking in protected mode. This can normally be accomplished in a few weeks or a few months with the help of third-party libraries and DOS extenders for Clipper.

Developers can give their customers the features they want without the huge risk and development cost associated with converting an application to Windows. Eventually, as Windows development environments evolve and the tools and languages become more stable, it may be practical and desirable to complete the tranformation to run as a Windows application rather than in a DOS box window. The developer I mentioned above was wise enough to take my advice and spend a lot less time writing a new system and little more time educating his customers. He tells his customers: "You don't take a boat to Denver, and you don't take a car to China."

TOUGH LOVE

In the early 60's, manufacturing giants who made home appliances, hi-fi equipment and televisions tried to "push" a new paradigm for the home onto American consumers. The fallout from this debacle was a product which became known as the TV/Stereo Console. The objective was to create a product that would supply complete home entertainment in a neat package that was also a nice piece of furniture for the living room. It was quickly accepted that this was the wave of the future so these products gained immediate acceptance despite the fact that they were inferior in performance to systems that consisted of separate components. Such products no longer exist because the consumer "wised up".

In the 90's, Clipper programmers are being "pushed" by other developers to convert their legacy applications to Windows or to even drop support for these applications completely and move over to the new paradigm by finding new customers or by dragging the old customers, kicking and screaming, into the new world. True, some of the force comes from "pull" by customers who have already adapted to the new world but much of the customer pull comes from a misunderstanding of the nature of the new paradigm and how it affects the way we do our work. As each legacy application is converted to Windows (at enormous cost), the customer will wonder why he paid so much money to create an application that is less productive and less reliable than the Clipper application that served him so well for so many years. Eventually, the users will start to understand why they will be better served by programmers who can help them build a "hybrid" of new paradigm applications like word-processing and desktop publishing and old paradigm applications like database management and data-entry. This hybrid environment will consist of "bridges" between DOS, Windows, OS/2, UNIX and others. Software developers have a responsibility to their customers. We talked them into buying computers and software with the promise that we would always be there for them. We need to be honest with them and ourselves and resist the temptation to move them into an environment that we cannot support, that we do not believe in, or cannot return the investment of time and money. I once had a sign over the door in my office that read: "49 out of 50 people will tell you why something can't be done. 1 out of 50 will show you how it can be done." Clipper developers are unique. We are the 1 in 50. That's why we use Clipper instead of dBASE or FoxPro. We know when to use Windows, when to use OS/2 and when to use DOS. If your customer says he won't use a software product that isn't a Windows application, then I suggest you turn him over to a VB or FoxPro programmer and don't look back. Wait for VO. It isn't quite ready for most of us, but when it is, it will be great. Like the prodigal son, your customer will come home and all will be forgiven.

RIDING THE SMALL WAVES

Software developers often get in trouble because they cannot hear what their customer is saying or they respond to the rhetoric that the customer has picked up from the magazines and other developers rather than the real meaning of their message. Most of the time, customers want small changes, not sweeping changes to their working environment and their applications. Windows is such a major paradigm shift that simply converting Clipper applications to Windows is not possible. Computer Associates promised that this would be possible via their new product, Visual Objects (VO) but after the dust settled we all discovered that if we want to write Windows applications we had better start from scratch because the old application code is just not compatible. I fell victim to this kind of thinking myself and even wrote a white paper called "Migrating Clipper applications to Visual Objects". I wrote the paper while attempting to convert my Clipper library, and even though much of the code conversion was possible, the end result was an application that wasn't nearly as good as the original application running in a DOS box. I deluded myself and some of my customers into believing it was possible even though, deep in my soul, I knew it was not practical and would be a waste of time. I believe in Windows and I believe in Visual Objects. Windows is the operating system of the future and Visual Objects is the development language of the future. Both products are magnificent in concept and deserve to be highly successful. Some day, they will come together along with other third-party tools to give us the ability to create database applications that will soar above anything that can be accomplished in DOS. I don't believe, however, that the operating systems, the languages, the development tools, or the users are ready for the complete migration to Windows. Database applications require a much more stable environment than word- processing, desktop publishing, games, or graphics applications. Never has there been a less stable, or more complicated environment than what has been served up to us in this new paradigm. The big appeal for Windows is the promise that it will give us user- interface standards and connectivity standards that will make it possible for anyone, without training, to use a computer. It's understandable, if your'e developing an operating system for use in the home why you would set this as an objective. What isn't understandable is why we would want to establish this as the model for business. Business has never had any problem adapting to computer systems that require user- training. On the contrary, the most popular business applications, like Word Perfect and Lotus 123, were not at all user-friendly and sold millions of copies of after-market books and an entire industry was developed to help train the users.

When asked to predict the future I can't control my urge to get more philosophical than technical. My favorite philosphers are those who tell us how things "will be" rather than tell us how things "should be"., i.e. "Future Shock". In our business, we must not only be sensitive to future shock in our customers, but also to the effect of "Revision Shock" or we can find ourselves quickly out of business. MicroPro, the developers of WordStar, were the first in the microcomputer software business to be dealt this painful truth and they didn't survive. There are people who will always be looking for the "big bucks" or the "big thrill" by riding the leading edge of the technology wave. It takes a lot of skill and hard work to do this successfully. Most of us have been on this leading edge once or twice in our lives and have either succeeded or failed greatly. Others have jumped on the wave because of a fear of being left behind with nowhere to go. Those of us who have been around for awhile know that each technology wave is followed closely by smaller waves that are much less turbulent yet offer the same amount of opportunities. Experienced programmers and consultants have also discovered that it is better to respond to "pull" from their customers than to "push" from their suppliers. You should ask yourself "How much of my development efforts are being influenced by other software developers and how much is being influenced by my customers?" Here's an excerpt from a letter I received from Jan Blum, one of my customers whose Clipper application I have been maintaining for the past year. She says:

"It is a principle of nature that before and after every expansion, there is a contraction. The market and the society are the same. We've been expanding for a long time in the software and hardware world. Those of us in business are contracting for a minute now. We've spent a lot of money and are analyzing our return and catching our breath. We are not ready for more changes that don't work. We are feeling more cautious. I'm not near as ready to buy the latest, the newest, the hottest, the fastest. I don't envy those that do/can. I want something that is solid, not flashy. There is a little anger, a little fear, a sense of having been a guinea pig for the market. I'm contracting. I'll push forward again. But it will be AFTER a pause and I'll be wiser this time."

UNDERSTANDING OUR NICHE
The world of software development is so much different today than it was 10 years ago. For one, the "niche markets" are much larger than they were because the overall computer market has grown by an enormous factor. Each vertical market or niche market has a life of its own. These markets do not react to vaporware announcements and are much easier to predict and service than the larger horizontal markets. Clipper is an example of a niche market that is still very much active on an international scale and will continue to be active for many more years. There are several reasons why I am making this prediction:

1. To many Clipper developers and database application users, Windows database applications have not yet made a strong enough case that they provide a better solution than a well-written Clipper application running in a Windows or OS/2 "DOS box".

2. DOS and Clipper are much more mature and stable than both the Windows operating system and Windows development platforms.

3. A Clipper developer with 5-10 years of xBase programming experience can develop a robust database application much quicker than a Windows developer with only 1-3 years of experience.

4. Most large Clipper applications under DOS load and run faster than most Windows applications with the same functionality.

5. Clipper applications will run on older hardware.

6. There are hundreds of thousands of Clipper legacy applications being used in businesses every day. It is far easier to upgrade an existing application with new features and a new look that use improvements in DOS (like Windows and OS/2 DOS boxes) than to convert it to Windows.

7. Converting a Clipper application to a Windows application is nearly impossible without completely rewriting the application.

Both Windows 95 and OS/2 have introduced a better DOS than DOS. This will give new life to Clipper legacy applications and make them work and look better without needing to change any code. Now it is possible to upgrade a Clipper application with full CUA compliance and mouse-support by simply using an add-on library or upgrading to Clipper 5.3 and a few minor code modifications. The new "better DOS-boxes" will give you a graphical mouse, sizable windows, user-selectable fonts, multi-user support and better memory-management.

THE NEW POLITICAL LANDSCAPE
The conventional wisdom in the software world is basically an understanding that Windows is a "black-hole" that will swallow up everything else including DOS, OS/2 and maybe even UNIX. Programmers have resigned themselves to the fact that one way or another they will be working for Microsoft or will have to go back to the farm. This new wave of thinking comes from the enormous influence of MicroSoft and their desire to control our workplaces and eventually our homes. It seems to me that many Clipper developers are accepting this as some kind of "fate" rather than seeing it as an "opportunity". Possibly this attitude comes from the fact that most products on the shelves at your local computer store say "MicroSoft" on the label and every PC comes preloaded with MS-DOS and Windows. There are those of us who have no problem living in a world in which a single monopolistic giant tells us "the way things ought to be" and will adapt very well to this new system. I can only predict that this may be the way of the near future (next 5 years) but is certainly not the way of the 21st century.

Who would have ever thought that Big Blue (IBM) would be the underdog in this new "race for cyberspace", but I'm suddenly finding myself rooting for them with a vengeance. Why? Because we need choices. We all became Clipper programmers because Clipper was a much better choice than the "more popular" dBASE. MicroSoft's monopolistic practices are crying out for U.S. government invervention and it is very likely that a MicroSoft "break-up" will occur before the end of the century that will lead to the "De-Installation of Windows". IBM is betting heavily that this will happen and have invested a lot of money in OS/2. Several million developers and users are also believers and have jumped on the OS/2 platform. In fact, the publishers of OS/2 Professional Magazine refuse to install a single Windows product on their computers.

CONCLUSION

The more some things change, the more others tend to stay the same. Would you rather read a book or constantly gaze at a computer screen? Is a push-button transmission really better than a stick-shift? Will a mouse replace a keyboard for data-entry? When will the world adopt the metric system? The future has some interesting surprises in store for us, but fortunately, the Gaia principle will keep us from self-destructing. I look forward to writing my final article about Clipper just before my retirement in the year 2035.

Biography

Roger Donnay is the president and founder of Donnay Software Designs, a Boise, Idaho, USA firm specializing in the development of programming tools, dynamic-linking systems, and database management systems for Clipper.

Roger is the author of dCLIP (tm), a DBMS library, IDE library, dynamic-link system and tutoring system for Clipper and Time-Cube (tm), an appointment scheduler for Clipper.

Send your comments to:

DONNAY Software Designs P.O. Box 16330 Boise, ID 83715-6221

Voice - 208-331-2516 Fax - 208-331-2621 BBS - 208-331-2623 CIS - 73227,1225



Rebuttal by Terry Carmen

Subject: Re: Back To Future

Date: 29 Jun 1996 15:12:41 GMT

From: tpcarmen@servtech.com (Terry Carmen)

Organization: Meadowbrook Software

Newsgroups: comp.lang.clipper

In article <4r2878$8t3@server2.rad.net.id>, Andi Jahja says... > >I Would like to Share The Following Article of Roger Donnay:

Nice aritcle, but he's missing the point.

I don't especially care if my customers want a DOS app, or a Windows app or a Unix app or something to run on an HP-41 calculator. If they have a need (real or perceived) and money, that's all the justification that's necessary.

Unless they want something that simply won't work as they expect it to, it's not my responsibility or (or even option) to "reeducate" them.

Donnay says "If your customer says he won't use a software product that isn't a Windows application, then I suggest you turn him over to a VB or FoxPro programmer and don't look back."

"Let them eat cake"? Send them over here, I'm thinking of buying a new car and would like to pay cash.

He also says "Wait for VO. It isn't quite ready for most of us, but when it is, it will be great. Like the prodigal son, your customer will come home and all will be forgiven."

Not likely.

The effort required to get back a lost customer is almost the same as is required to find a new customer (sometimes more, sometimes less, depending on what they think of you).

Once they have found that you can't (or worse can, but won't) fill their needs, they'll be gone like a puff of smoke in a hurricane.

The dark reality is that, for whatever reason, Windows comes on pretty much every PC built, and people are conditioned to want it.

It makes them feel good if they can buy software that does what they want and runs under Windows.

When they can't buy software that does what they want, the only reasons they come up with are:

[1] They're using the wrong O/S

or

[2] Their software vendor is incompetent

The answer isn't #1, since Bill Gates is a billionaire and is by definition rich and sucessful, and they do not blame themselves because they have purchased the same thing millions of other people have.

Guess which one they pick?

It's much easier (and more profitable and usually better) to give people what they want, instead of what you think they should have.

If they say "Windows" and you say "DOS", there's a good chance they'll say "goodbye."

Terry

There are many paths from Clipper to Windows... [20th July 1996]

As I see it, there are many paths from developing Clipper apps for DOS to writing 16 bit apps for Windows 3.10 & 3.11 and 32 bit apps for Windows'95 & Windows NT. Except for Borland Delphi which is pascal based, the rest of the following windows development have their roots in XBase :

16 bits Windows

  • CA-Clipper 5.2e + FiveWin

  • CA-Clipper 5.2e + Clip4Win

  • CA-VO 1.0c

  • CA-dBfast


  • UltimAde (VO specific)


  • Microsoft Foxpro for Windows

  • Microsoft Visual FoxPro


  • Borland dBase for Windows

  • Borland Visual dBase 5.5a

  • Borland's Delphi - Pascal Based

    32 bits Windows


  • CA-VO 2.0

  • Borland's Delphi - Pascal Based
  • Welcome to Clipper... Clipper... Clipper


    In 1997, then using Delphi 3, I had already created 32-bits Windows applications for HRIS, ERP and CRM. In 2007, using Ruby on Rails, an AJAX powered CRM site running on Apache & MySQL was created and I am now using Visual Studio .Net 2008 to create web-based projects and Delphi 7 for Win32 applications using SQL2005 & DBFCDX.

    So, why then am I reviving the Original Clipper... Clipper... Clipper via a Blog as CA-Clipper is a programming language for the DOS world ? Believe it or not, there are still some clients using my mission-critical CA-Clipper applications for DOS installed in the late 80's and up to the mid 90's. This is testimony to CA-Clipper's robustness as a language :-)

    With the widespread introduction of Windows 7 64-bits as the standard O/S for new Windows based PCs & Notebooks, CA-Clipper EXE simply will not work and it has become imperative for Clipper programmers to migrate immediately to Harbour to build 32/64 bits EXEs

    Since 28th January 2009, this blog has been read by 134,389 (10/3/11 - 39,277) unique visitors (of which 45,151 (10/3/11 - 13,929) are returning visitors) from 103 countries and 1,574 cities & towns in Europe (37; 764 cities), North America (3; 373 cities) , Central America & Caribeans (6; 13 cities), South America(10; 226 cities), Africa & Middle-East (12; 44 cities) , Asia-Pacific (21; 175 cities). So, obviously Clipper is Alive & Well : -)


    TIA & Enjoy ! (10th October 2012, 11:05; 13th November 2015)


    Original Welcome Page for Clipper... Clipper... Clipper

    This is the original Welcome Page for Clipper... Clipper... Clipper, which I am republishing for historical and sentimental reasons. The only changes that I have made was to fix all the broken links. BTW, the counter from counter.digits.com is still working :-)

    Welcome to Chee Chong Hwa's Malaysian WWW web site which is dedicated to Clipperheads throughout the world.

    This site started out as a teeny-weeny section of Who the heck is Chee Chong Hwa ? and has graduated into a full blown web site of more than 140 pages (actually hundreds of A4 size pages) ! This is due to its growing popularity and tremendous encouragements from visiting Clipperheads from 100 countries worldwide, from North America, Central America, Caribbean, South America, Europe, Middle-East, Africa and Asia-Pacific. Thanx Clipperheads, you all made this happen !


    What is Clipper ?

    You may ask, what is this Clipper stuff ? Could Clipper be something to do with sailing as it is the name of a very fast sailing American ship in the 19th century ?

    Well, Clipper or to be precise, CA-Clipper is the premier PC-Software development tool for DOS. It was first developed by Nantucket Corporation initially as a compiler for dBase3+ programs. Since then, CA-Clipper has evolved away from its x-base roots with the introduction of lexical scoping & pre-defined objects like TBrowse. As at today, the most stable version ofClipper is 5.2e while the latest version, 5.3a was introduced on 21 May 1996.

    As at 11th November, 1996, an unofficial 5.3a fixes file was made available by Jo French. See the About CA-Clipper 5.3a section for more details. BTW, Jo French uploaded the revised 5.3a fixes file on 20th November, 1996.

    Latest News

    The latest news is that CA has finally released the long-awaited 5.3b patch on 21 May, 1997.

    For 5.3b users, you must a take a look at Jo French's comments on unfixed bugs in 5.3b.

    BTW, have you used Click ? If you're a serious Clipperprogrammer and need an excellent code formatter, Click is a natural choice. How to get it ? Simple, access Phil Barnett's site via my Cool Clipper Sites.

    32-bits Clipper for Windows ?

    Have you tried Xbase ++ ? Well, I have and compared to Delphi (my current Windows programming tool of choice), I'm still sticking to Delphi.

    Anyway, you should visit the Alaska Home Page. Give it a chance and then draw your own conclusions !.

    The Harbour Project

    Is this the future of Xbase ? Take a look at at the Harbour Project

    You are Visitor # ...

    According to counter.digits.com, you are visitor since 3 June 1996.

    If you like or dislike what you see on this website, please drop me a line by clicking the email button at the bottom of this page or better still, by filling out the form in my guest book. If you are not sure what to write,click here to take a look at what other Clipperheads have to say.