Virtual Pascal, a view from the helicopter. ---------------------------------- Somebody who read my gpctxt.txt asked if I could write a similar critique/analysis for VP. I've brooded on it for a week or two, and decided to do it. I'm not as satisfied with the result as in the GPC case, simply because the GPC case is more multifaceted, and VP is pretty much a slamdunk. There is not much too learn but that the community doesn't participate in the development, and there is an enormous maintenance gap. The usual disclaimers apply, and I accept critique/additions/opinions to this document. I know that I'll be considered heavily biassed due to my long-term FPC involvement, and somebody who says that I judge VP on FPC oriented baseprinciples is probably right. Nevertheless I hope it at least gives a somewhat consistent view of my opinion on the matter. The main question to answer is the same as gpctxt.txt's: "why didn't it grow?", but that is in VP's case a bit like kicking in an open door. Introduction ------------ Virtual Pascal is yet another 32-bit Pascal compiler. Maybe not the oldest one (GPC and FPC are actually older), but from the surviving non-Borland owned ones, the first that rose to prominence. Dialect level is Delphi 2ish, but its userbase is generally still TP oriented. Some even experiment with OWL. I don't know the exact history, but assume it started on dos, went to OS/2 a bit later. Some time later also to Windows, and then finally to Linux. It was very popular in the BBS scene in the mid and 2nd half of the nineties. After 2000 to my knowledge no significant new development took place. In late 2003 Allan announced plans to stop with VP, but massive pleas and support offerings on the maillist convinced him to give it another try. While afaik some RTL maintenance was done by Veit Kannegieser (6) in this period, nothing much happened otherwise, and Alan finally canned the project in 2005 (2). Of course this triggered another torrent of support pleas (3). A few years later Allan set up a community at the ning community site (4), where a re-spin of the last version with accumulated fixes was being planned (in 2009)(5). Allan has made it clear several times that major development on VP will not be restarted. This re-spin is still pending, over eleven years (feb 2009 - jan 2020) after being announced. In mid 2017 the NING site was abandonned, and a facebook group was set up. There is some minor traffic there, but the simplest user questions only, nothing about development(last checked early 2019) (2) http://web.archive.org/web/20051229123611/www.vpascal.com/news.php (3) http://web.archive.org/web/20060105130905/www.vpascal.com/comment.php?comment.news.16 (4) http://vpascal.ning.com (5) http://vpascal.ning.com/forum/topics/do-you-have-a-small-bugfix (6) Some of which has not been merged back and is still waiting for the respin afaik VP's strengths ------------- The typically cited advantage of VP is its stability, specially wrt the textmode IDE. I think also the fact that it does what it should do fairly well. IOW it has a certain completeness for the more basic tasks. (though those are more from a 32-bit TP than a Delphi viewpoint) Also, the older targets (Dos, OS/2) were mostly finished before the focus shifted to newer OSes (Windows,*nix). These are therefore still the VP strongholds, but a problem is that these strongholds mostly attract the kind where users are only interested in minimal maintenance of old codebases, together with a few tinkerers and minimalists. All of them being absolutely wary of any kind of fundamental change, and there are no potential developers/contributors that could/would support or propel a major project revamp. VP also supports OWL, Borland's first attempt at a GUI library. (win3.x style) by patching Borland OWL sources on install if found. I don't know how complete this is. VP's weaknesses. --------------- There are several: - The main problem is the lack of maintainability of the project, which is a compound problem that shines through everywhere. - the compiler source is pure assembler - Crucial source and headers are patched proprietary (e.g. Turbo Vision, sysutils, OWL) sources . Borland has gone through so many changes that the (afaik verbal) agreements are hard to verify, change or amend. The tool to patch the sources is win16, commercial and no longer maintained. (patch/universal diff not possible since the patches must be free of copyrighted material). This makes development on 64-bit systems difficult using the current toolset. Possibly there are more 16-bit tools used. (hmm, while a burden, dosbox could be the solution here) - documentation is managed using Word, exported via RTF and processed using proprietary tools. (exact status and required word version not known, but I doubt it is the most recent one. More likely something that was already old in 2001-2003 like word 95 or 97) - support for some platforms is done via binary file convertors. This potentially (1) makes exploiting platform specific features (PIC, setting linker options) and properly parameterising these hard. - The community (see separate paragraph) - The lack of maintenance releases for the last fifteen years, as well as building a knowledge base using bugtrackers,testsuites etc. Note that while for open source projects the above problems are worse, even when continuing a project commercially, a totally outdated tooling, an unmaintable codebase (compiler) and a legal status with red tape everywhere is not the healthiest of situations. Probably nobody that has touched it in fifteen, near on twenty years, not even to build a new version. Some of the above issues are fixable with a bit dedicated hard work (like e.g. the documentation), some are nearly insurmountable (the asm compiler) or very hard (the copyright issues). There is simply too much that needs to be reengineered from the ground up, making the worth of what is left doubtful. A continuation would be nearly a new project from the ground up. Worse, the extremely conservative community probably won't accept heavy changes, like going through a transition period where Borland sources are replaced with cleaned up (dialect wise) sources from FPC. This is the fundamental problem it seems, most of the community underestimates the amount of work and overestimates the reusability of what already exists by several orders of magnitude. One could question if that community matters at all though. OTOH abandoning the little community left fundamentally erodes the reason to try to update at all. (1) this is from a quick glance. Admitted, it (binary converters after linking) might be fixable easier than that FPC gets a binary linker for all platforms. Still it indicates that some of the platforms never got beyond the initial stage. And FPC has at least an alpha level ELF linker and slowly even a debugger (fpdebug) :) VP community ------------ Primarily the problem is that the VP community is purely an user's community. And then mostly not very active users. The people that make up the VP community seems to be roughly similar to the kind that still use TP. The audience is mostly students and other newbies, and a few oldtimers and hobbyists maintaining old codebases. Some slightly more serious people are doing dos-style hardware interfacing, but usually also in maintenance-only mode. This latter category started disappearing after 2008. Like TP, their numbers, and worse, the activities of the remaining ones are dwindling. I've a feeling that a large percentage of the newer users seems to have tried FPC in the (far) past, but found it to complicated or too much in a flux. Keep in mind that most of this group crosses from TP, not Delphi. The users are not used to work with a moving target (even the Delphi versioning is already complex in their eyes), and expect commercial finishing touch. Moreover they seem to be unable to deal with systems complexer than TP (or consider it not worth the effort). Even TV is often already a bridge too far, often haven't learned any new system or way of programming for (a) decade(s). In general, there is hardly any development of new code, save for the repetitive attempts of a few total newbies (and the last few years, that seems to be disappearing even). Worse, it seems it pretty much has been this way for over two decades. (2002-2024) This is a bit of a problem, because, this way, the community is totally dependent on the developer(s) doing everything. Isolating complex bugs is beyond most users. There is little to none non-trivial 3rd party reusable development, and the Delphi compatibility is 1.0.x like, too little to start mass porting Delphi software. Together with the inexperienced community that more or less caused the failure to restart development in 2003. The VP situation is worse as with FPC 1.0.x, and that took 3-4 experienced compiler developers every bit of free time for 5 years to take it to the next level. Even though VP probably won't be opensourced, I doubt it really would change anything if it did. Even if it had in say 2003 or 2005 it wouldn't really have mattered much (though the chances then would have been better than now, but still very slim). It ate up whatever head-start it had in the 1997-2002 timeframe, and after that the people that were able to do anything about it already had moved on. Worse, this kind of community probably won't accept any change that upset stability or could force changes to the way they work (e.g. cleaning out DOS cobwebs, reducing relience on commercial products) anyway, and would continue using the old versions, contributing next to nothing to the new development effort, not even serious testing and bugreporting.