What happended to visual parse++?

We have been using visual parse for many years and need to get new
license keys. They don't answer their phone, business searches for
sandstone technology, the company name, get no hits. I know that
others on this newsgroup have used this tool. Their license is tied to
specific machines so as the machines die, so does the software. We are
down to one machine that can run the software.

Does anyone have any contact information? Their website lists their
address as lahaina, HI and I know the principal is named william
donahue but haven't had any luck getting anyone.

Please help
[The WHIS for stand-stone.com lists a phone number in Hawaii and one
near San Diego. Have you called them? -John]

<jim.barstow@gmail.comwrote in message news:06-12-051@comp.compilers
We have been using visual parse for many years and need to get new
license keys. They don't answer their phone, business searches for
sandstone technology, the company name, get no hits. I know that
others on this newsgroup have used this tool. Their license is tied to
specific machines so as the machines die, so does the software. We are
down to one machine that can run the software.
>
Does anyone have any contact information? Their website lists their
address as lahaina, HI and I know the principal is named william
donahue but haven't had any luck getting anyone.
>
Please help
[The WHIS for stand-stone.com lists a phone number in Hawaii and one
near San Diego. Have you called them? -John]

I have had no luck contacting them either. This is very bad. Many emails and
phone calls that go unanswered. Too much sun and surf in Hawaii?

I am just looking for the source files that begin with "sslt" Any one out
there have those files that would be willing to send them to me?

-alan sung
Rapid Realm Technology, Inc.
Hopkinton, MA

I also have had my emails and phone calls ignored for about a year
now, I have an old machine that I keep around only because it has the
Visual Parse++ license on it. Apparently they're still selling the
product though, they have an ad on Google, but they are completely
ignoring any support request. could speculate that Bill Donahue
has died and whoever controls the product is incapable of supporting
it. It is a fraud for them to advertise the product with support when
there is none.

"David Bridges" <dave.bridges@etamicusa.comwrote
Apparently they're still selling the product though

I don't think so because I had an order placed through their online
web page ordering system and nothing has been billed to the credit
card or delivered.

-alan sung
Rapid Realm Technology, Inc.
Hopkinton, MA

I don't know what happened to Sandstone or Visual Parse++, but I have
put an inquiry in with the last person I know who had access to Bill
Donahue and the Visual Parse++ sources. If I can make reasonable
arrangements such that I can sell and support Visual Parse++, I will
post notice here. Unfortunately, I can't promise more than that.
Still in the VP++ situation, I hope I can be of help.

My guess is that as they stopped making money on it tools
are very hard to make money on simply abandoned the business.

Software tools perenially suffer from a modified form of "the crisis
of the commons". Writing a quick-and-dirty tool is generally not
hard. Therefore, a lot of "free" or near free tools spring up, and
sometimes make a little money for the author. However, the
maintenance cost of continuing to keep the tool working in the face of
changing environments, such as new versions of the compiler and
evolving language dialects (even C isn't the same it was in the 70's,
and many users have migrated to Java or C# or futher away to Python or
Ruby or Haskell) is prohibitive. Moreover, customers are loathe to
pay very much for a tool, when there is a low cost tool which is often
"good enough" available. Very seldom does the customer realize that
by using such a tool, they are likely to end up with no support and no
upgrade path. (I'm not surprised that one person wrote they kept a
legacy machine just running an old copy of Visual Parse++ that they no
longer can buy a replacement for.) Thus, it is cheapest for most
customers in the short run, to take a short sighted view and that view
mitagates against the development of a sustainable software tools
industry, because it makes it difficult for people to maintain
products beyond a fairly low level of quality. It is particularly
unfortunate when this problem hurts people who are willing to invest
in their tools, and hence my goal to "rescue" VP++ although I know it
will be mostly a "labor of love".

Being on the other side of it, it is equally not fun to get calls
where all the original developers have left, and there is some
critical software using an outdated version of my product (on an
outdated platform that is no longer available), and the person wants
free support to get it working on a new platform.

Recently, I added "backwards compatibility" support into Yacc++ to
ameliorate that problem somewhat. With it, the new version can
emulate the old versions, including some (but not all) of the old bugs
that have been repaired. That at least gives one a fighting chance of
getting the old software to work.

The other partial solution to the (outdated software) problem is
offered by "open source".

Aside: In fact, I am preparing an open source (GPL) version of
Yacc++ for release in the next couple of weeks. The goal is to
relase a version that has the functionality of 2.0 or 2.1, but
with all the latest bug fixes. And, yes, I just fixed a 17 year
old flaw in the last couple of weeks. Sometimes it takes a while
to see what exactly is wrong and how it should be fixed
(especially if the bug is in an obscure corner where most code
doesn't get affected by it and when one can put patches around to
make that corner smaller and less accessible, which is how one can
get by for 17 years without being bothered by it).

With an open source (or source available version), one can get
the sources to a version and hold onto them. That's only a partial
solution, because even with the sources, a client doesn't often have
the expertise to fix things when "something" breaks. To make that a
complete solution, one needs to make certain that someone
knowledgeable stays interested (which probably means funded) in
keeping the project alive.

By the way, one of the problems with some open source projects
(especially small ones) is that there isn't one developer who stays
motivated, and instead one gets a whole series of splintered forks
where someone got interested in solving one problem and worked on it
for a while but abandoned it, and then another got interested in a
different problem and did a separate fork and abandoned that, and so
on. Moreover, you can't really blame the developers for that, they
are doing it to solve their problem, not yours, and it is easiest to
solve a problem if you don't worry about what other things you are
breaking and not worry about keeping something continuously working.

It's only a problem for smaller open source projects, because one
person can't get their mind around all of Linux, Apache, or Emacs,
while one can easily clone LEX to Flex to Flex++ or Yacc to BYacc to
Bison and BTYACC (and MKS Yacc and PCYACC). Moreover, it is easiest
to clone such tools from "first principles" (i.e. by starting from
scratch or near scratch). Thus, it is hard to support the notion of
compatiblity (much less) "bug compatibility" going forward without a
conscious effort on the part of the developers. The easiest course
for a small project developer is exactly the course which breaks
compatibility.

Note, we suffered from the same thing when we did Yacc++, it was
easier to build it from scratch than it would have been to take an
existing version of Yacc or Bison and modify it (and clearly more
legal to do so given how we wanted to sell it). Moreover, when
Terence Parr descided to do PCCTS version 2, it was easier for him to
start from scratch that to reuse his existing 1.x code (and it wasn't
that his 1.x code was at all bad).

To amplify that a bit more, it was easiest to write Yacc++ from
scratch, because one of our initial goals was to have easily
understood (by us) tables. We wanted tables we could "debug". The
compression and overlaying standard yacc did at the time, made the
tables how to decode. Therefore, the easiest solution for us was to
build a much simpler table processor. And, the reason we wanted
tables we could understand is because we were experimenting with ELR
parsing, and knew that the tables would have bugs, so we wanted to be
able to read the tables to track down those bugs. Now, that the
tables are really mature and secure, I suspect some day I will put in
yacc compatible table packing, just because it is easy and safe to do
now.

Just one person's rambling thoughts on the topic,
-Chris


Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)


P.S. To John, I apolgize that most of the content of this isn't
compiler related (aside for having started with the sorry state of
most compiler tools). I hope it isn't so far afield that it isn't
worth posting, since this is probably the only way to get to a large
audiance of VP++ (and other tool) clients. So, let me know, if this
is too close to spam.
[This message is entirely about compilers, what's actually involved in
writing and maintaining them. It's fine. -John]

I similarly have been trying to get a response from SandStone, to no avail--which brought me here. My poor old laptop with VP++ is on its last legs.

Today (after reading these posts) I dug up my 2000 CD of VP++ 4.0 and resurrected my correspondence with Bill Donahue. I installed VP++ from my original CD, on my new computer.

Instead of sending in the registration information to SandStone, I copied all the files ssvp????.lic from \winnt on my *old* computer (with VP++ installed) to the \windows directory on my new computer. The messaged saying there were 29 days to register stopped being displayed on startup.

According to Donahue's 2000 email, if you have good ssvp*.lic files in your \windows or \winnt directory, it doesn't look anywhere else to authorize your use of the program.

You may be able to install Linux on that old computer sooner than you expected! Good luck!

I am having the same problem, and we cannot find the installation CD anymore... Could some one tell me how to obtain the installation file (ssvp400.exe).

This will save us lots of time !!!

Thanks for the tips about license files.

Ditto thanks for the tip about the ssvp*.lic files. My problem is that we have the install set (v5.0) but don't have any .lic files anymore.

Is anyone willing to send me their ssvp*.lic files so that I can see if this works for me? Thanks.