25 replies to this topic

[Rob Donovan]

Hi,

Not sure on the 'legal' site of things here.

I have got a complete version of the bootstrap files. I have NEVER been given them by PROIV LTD or signed any legal documents.

The way I got them was to reverse-engineer them. Its not too difficult to do.

I guess I can show you HOW I did it, and I dont think there should be a problem giving you the file defs because I worked them out, otherwise you could not show anyone any filedefs. I'm not sure ?????

I have used this method a couple of times in the past to workout the phyiscal FD of files that did not match the PROIV FD, so that we could read the data.

I really dont know why PROIV are so secretive about them, I't ain't rocket science and whats the harm?

What do people think?

Rob D

[Dan Shannon]

Your supplier is being 'economical with the truth'.

PRO-IV will let you have a copy of the bootstrap file definitions if you have a development license and are willing to sign a non-disclosure agreement.

Perhaps try contacting them direct rather than via your supplier?

Dan Shannon

[Peter Davies]

That was the situation when I worked there.

Ask your supplier to ask PROIV.

PROIV USA was more than wlling to let these go if you signed the agreement.

The agreement was more geared around not blaming PROIV if you mess up your environment.

[Dan Shannon]

set rant_mode on
set serious_mode max

---

Right, let's have an argument.

The bootstraps are pretty fine as they are - they work!

If I was being cynical, I'd say that the reluctance to distribute the bootstraps is basically down to anti-competitive behaviour - the mentality that strives to keep all the PRO-IV tools market revenue in PRO-IV's bank accounts.

If it really was 'a massive drag factor' then why would Oracle publish their views and even source for many of their packages as part of the standard install? Granted the scale of the operation is different, but the same arguments still apply, and they manage so why can't PRO-IV?

Also, the changes from v4.0 to v4.6 were pretty minimal - a handful of changes which are VERY easy to apply to existing tools. In fact if you don't want access to new features you don't even have to update your tools...

What we get from PRO-IV is either downright ordinary (the Native bootstrap functions) or buggy (why can't I define interfaces properly in Studio) or enforces weird standards (Studio does with several areas, as does SuperLayer with nearly everything, and Forms Designer seems to be a law unto itself).

What's so damn good about the bootstraps being available is that they make PRO-IV much much easier to use - every site I've ever worked at used them to build system-generated functions to automate many tasks - and put the developer much more effectively in control of their own destiny.

In the end, hiding the bootstraps away behind confidentiality agreements and bureaucracy only serves to aggravate the development community. I personally can't see why on earth a confidentiality agreement should apply - it's not as if the information in the bootstraps contains earth-shattering information - it's a set of file definitions which tell us how the code's laid out!

SO - here's a serious suggestion for PRO-IV - why not simply publish the file definitions with each release and have done (I can see that the actual code is proprietary). That way all developers know where they stand on each release and can build, share, develop new tools and methods for using the language to EVERYONE's benefit. (I've said this before - your developers are your greatest allies when you're selling a language - if they like it they'll sell it for you.)

Ah, I feel much better.

---

set serious_mode normal
rant mode off

[Rob Fantini]

I agree that file defs should be part of each release.

I also think that the source code should be released and that a Linux like team consisting of all of us could submitt corrections and enhancements.

Pro4 could make their revenue by selling run-time licenses.

Also 1 development license ahould be free on each install.


Otherwise we'll be paying larger and larger fees for maintenence as fewer developers will be using pro4 every year.
I wonder if someone dares post the number of new development licenses purchased in the ast year?

Or the total number purchased in 2000 vs 1999 vs 1998 etc?
I bet the graph is on a downward trend. Pro4 needs to change its operating basis and having us help make the core product better is a start.

[Rob Donovan]

I agree too.

Lots of sites have versions of the bootstraps, PROIV LTD seems to think that no one has them and they have to keep it secret.

If they suddenly change the bootstraps so much, then people are just not going to go for the upgrade.

People on different sites have spent time to write Version control systems and their own tools for development. There is no way they will move to a new version without these tools.

Maybe, we should have a question.... How many people DO have the bootstrap file defs just to show PROIV LTD that it is not secret.

Not every one (I have yet to find anyone) likes Developer Studio. Yet there are lots of things that we are forced to do only in Developer Studio and cannot access in the standard @MOD functions.

Also, what exactly can they do to the bootstraps to make them THAT different, as Dan says 'they work'. The structure is fine, we just need extensions to them.

So what is going to be in version 5, a new method of maintaining functions??? Well so far we've had @MOD, Developer Studio, Forms Painter, Jade (didn't even make it out...) and now another one.... When will it end???

I wish they would concentrate on the MANY outstanding bugs with the standard kernel that we have, 1 or 2 of which are rather serious.

Well theres my 2 Krona worth!!

Rob D

PS. I've a feeling we will get no reponse to this.

PPS. Yes Dan, I'm on my way to bed, I know I'm up late again!

[Peter Davies]

OK, my turn.

Please remember, I am not longer with PROIV...

One of the biggest problems with this language is the bootstraps. We store the PROIV programs in PRO-ISAM files, a completely proprietary format that cannot be used by external programs.

It is tough for some people to use PROIV as there is no source control and therefore if you are using ISO or CMM methodologies, PROIV will not comply.

A single PROIV function is stored across many individual files. Why is this ?

Why not store a PROIV function in a single XML file ?

If you had 1 file = 1 function, we could use industry standard source code control tools. Also, PROIV could write a development tool in another language other than PROIV.
You could use file copy, not PROIV copy etc. etc.

If we can get our code into a standard file format, we won't have to rely on these guys so much for tools.

That does feel better.

[Joseph Serra]

I wholeheartedly agree with you Dan, and Peter had very interesting points.

It is clear that companies using ProIV really need that bootstrap files. Isn't it better to issue up to date versions, so we don't use incorrect versions (as I have seen on some sites).

I cannot understand why ProIV would not encourage other individuals and companies to develop their own development tools. Wouldn't this generate more interest and support in the language?

Besides, I am sorry to say, but I don't think ProIV have much of an idea of what the ProIV development community require. Developer Studio?

[Chris Pepper]

OK, since everybody is piling in!
(rant mode on)
What we need is a common, easily accessible format to handle native PRO-IV source code. IMHO the company I work for (and many other long term users) will never use Superlayer, Developer Studio (sorry Neil), Jade, 2whatever is cobbled together to make PRO-IV a bit of money this year and is never properly implemented and breaks in the next release' and (in our case) probably never even use the PRO-IV GUI! That's because they're all flawed and can't cope with the mass of existing code. Even the Debugger broke in 4.6!!!
Anyone with a huge pile of code might as well just go to another language.
I'm concerned with implement Source Code control and the only way I can currently do this is to extract the source code into documents I can put into a repository. If the bootstraps are taken away then I can no longer do this.
The only improvement which could be made is to allow PRO-IV function to be created using a standard text editor - to have some freely shareable definition which would allow individual functions to be programmed in the same way that other languages can.

Mr. Angry

[Mike Nicholson]

If I can speak just for myself a moment, and I don't really feel qualified to speak for anybody else, however small the community might be. This all sounds very nice and I'm sure that VIP will look pretty but remember that you are talking to the techies here not the users - the simpler the development tool the better as there's less to go wrong with it and it's much easier to navigate.

I'm not quite sure what you're planning on achieving by storing bootstrap information in XML (if I read your post right) but as long as you maintain the basic structure of the bootstraps I'd much prefer something along the lines of ProAide for day-to-day development.

I confess I am a little confused by your explanation of the direction you will be taking in the future - are you able to provide more details at the moment or is this considered confidential at this point?