xBase++ from Alaska Software was started as a way to make Clipper code run in Windows as a genuine Windows app. It has morphed and changed way beyond that, with enormous added functionality, ability to link to SQL databases easily, and much more. Alaska just announced they plan to focus on the cloud first, with being the desktop being secondary.
Quoting from their email:
Internet technologies have only played a secondary role within Xbase++ until now. Although we innovated in this area, the preferred way of developing applications still was desktop or server- centered. However, the IT landscape has changed in the past few years and will continue to change in the future. We clearly see a point of time ahead of us where desktop applications will be banned for various reasons. Be it because of security or deployment considerations, or due to complex infrastructure requirements. Because IT desktop infrastructure-related costs are constantly increasing while agility keeps decreasing, there will be a point in the future where desktop applications are superseded by web and mobile applications as well as virtualized desktop applications.
Said that, Alaska Software herewith announces that it is starting the process of aligning its product development and product strategy for transforming the Xbase++ development tool into a cloud-first development platform. This alignment will also affect our plans to deliver a next-generation Visual FoxPro toolchain for the Windows desktop in such a way as that the UI experience and deployment become cloud-first
Our vision from a development tool perspective is that any Xbase++, Clipper or Visual FoxPro developer should be able to publish an Xbase++ application to the cloud simply with a push of a button, and that customers can use this new application either via the web browser, a mobile device or via a public API. Additional application features, such as error and performance monitoring or log analysis, should be accessible at a central location. In fact, any Xbase++, Clipper or Visual FoxPro developer should be able to adapt the SaaS or BaaS business model with a minimum effort and this way create new streams of revenue based on existing knowledge and source code.
Currently, in June 2016, we are working on a Clipper conversion to Windows for a fraternal order in another country. Membership ranks and titles are quite complex, made even more complicated by not having the original source code. It just takes time, and lots of experience. We can do the same for you, regardless of how complicated your DOS-based application is.
This conversion is an excellent example of why mission-critical applications often cannot be simply ported to an existing software package. The application was custom-written to meet their exact needs and the business logic and data must be converted a modern, also custom-written platform. This is what we specialize in.
One of our services is decompiling Clipper executables, and we did that for this client. However, the decompiler sometimes cannot restore original variable names and instead tokenizes them, making the code difficult to understand. In addition, the original code uses arrays extensively, resulting in decompiled code that is indeed, spaghetti. That’s just how people coded in the 1990’s in Clipper. We know how to convert it to a platform that will run in any version of Windows.
In 2015 we completed a two year conversion for a household name institution that handles all their travel visas, including printing visas from any country to any country. The specs for the visas are entered by users into the system and printed, filled-out, as needed. No existing software on the market can do this. Hence the existing code had to be moved to a Windows platform.
Let us know if we can help convert your DOS-based program to Windows.
Visual FoxPro, a Microsoft product, can often be used to convert Clipper applications to Windows since the two products have quite a lot in common.
Clipper and Visual FoxPro emerged out of dBase in the late 1980’s. They share a common language base and have similar data file structures. This means that existing data files can often be used with little or no changes needed. Plus, at least some of the Clipper code can generally be used directly or with little modification in the FoxPro application. This greatly reduces the cost of conversion and speeds development time.
The database file structure (DBF files) in Clipper and Foxpro are virtually identical. Thus, Clipper data files can be used as is. No conversion is needed. Clipper often used FoxPro index files. If so, then the indexes can be used directly. If not, the the Clipper index files can easily be converted to the faster, more stable FoxPro index format.
FoxPro also supports non-native data formats like SQL Server and Oracle. However, this require changing how data is accessed inside the program.
While it is true that Microsoft will not be releasing future versions of Visual Foxpro, it is a robust and stable platform with a community of developers supporting it. Clipper hasn’t been updated in twenty years, yet there are still a multitude of Clipper applications still running. Developers will be supporting Visual Foxpro years from now.
xHarbour compiles and runs Clipper code as a console applications in Windows with few if any changes needed.The console application will look and feel like the Clipper application. However, it will be a true Windows application and will run in any version of Windows, including 64-bit. It will also be able to address USB printers, which DOS-based Clipper applications can not do.
Sometimes, this is all a client wants or needs, with the added benefit that no re-training is needed since the new xHarbour application performs exactly the same as the Clipper application.
xHarbour will only compile native Clipper code. Some Clipper applications used third party libraries of code for increased functionality. If so, that code may need to be rewritten.
With xHarbour, an existing Clipper application can be converted to Windows with minimal time and cost, assuming that a DOS look and feel is suitable for the purpose.
FoxPro and Clipper programs are created from source code files that are assembled into an executable program by compiling then linking the code to create an EXE that can be run without needing the source code. Decompiling FoxPro and Clipper recovers source code from EXEs by using specialized programs.
Over the course of years, Clipper and FoxPro source code often disappears or is out of date. Migrating these applications to Windows and the cloud is far easier is source code is available because then you can determine exactly what the application is doing.
We have decompilers for both FoxPro and Clipper. The FoxPro decompiler always works, assuming the code wasn’t encrypted.. The Clipper decompiler often will but doesn’t always. It depends on how the program was linked. We charge $75 to decompile and you only pay if it was successful.
FoxInCloud takes Visual FoxPro code and converts it run in the cloud on their servers, automating 98% of the work.
Wth FoxInCloud, your Visual FoxPro application can run on any device and any operating system, because it will be web-based. Thus, a Clipper application can be converted to Visual FoxPro then to FoxInCloud.
Servoy is a rapid application development suite that shares language syntax with Visual FoxPro.
“Servoy is the ideal dynamic and data-centric development platform for Visual FoxPro developers. Beyond a great platform to evolve Visual FoxPro applications, Servoy also offers cross-platform (Windows, Mac, and Linux) for development and runtime, cloud computing scenarios, and cross browser with mobile web development. Servoy is the logical evolution for FoxPro applications and VFP developers into the next decade.” – Ken Levy, former Microsoft Visual FoxPro product manager
Thus, Visual FoxPro applications (and Clipper applications that have been converted to Visual Foxpro) can live on in the cloud.