Pro-iv Bootstraps file defs
Posted 13 February 2001 - 06:05 PM
We have a development version and licence of pro-iv. I wish to have a the file defs for TERMMAST, FLDSPEC SYSDEF etc for our version of Pro-iv to enable enhanced options for users like showing devices and to write utilites to search code as everyone knows how good the ones are that are supplied with proiv. I have requested them from my suplier and they say that PROIV will not release definitions of the bootstrap files. I just can not believe this to be true. If it is true could someone let me know. We will have to change languages.
Thank you in advance for a reply
Posted 13 February 2001 - 06:34 PM
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?
Posted 14 February 2001 - 03:47 AM
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?
Posted 14 February 2001 - 11:11 AM
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.
Posted 14 February 2001 - 04:11 PM
Firstly you are vunereble to PROIV changing the file design.
As we all know the files are not in a great shape due to us
having to modify defs with the community in mind, which is
a massive drag factor on being able to create better source
storage structures and development tools. This model will
be changing with version 5.0 as we will adopt an API approach to accessing source code and so reduce our change restrictions.
I would also like to suggest that if these tools are so desperatly needed it is a shortfall in the development environment and we as a development community to try to resolve it.
** Why not post your tool requirement here or with PROIV
so that they may be considered for core product or used by
other members of the community some probably have the tool you need **
Posted 14 February 2001 - 04:53 PM
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
Posted 14 February 2001 - 05:15 PM
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.
Posted 14 February 2001 - 06:40 PM
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!!
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!
Posted 14 February 2001 - 10:20 PM
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.
Posted 15 February 2001 - 07:04 AM
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?
Posted 15 February 2001 - 12:47 PM
(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.
Posted 16 February 2001 - 09:01 AM
The use of I and individual within some of the replies does
not smack of community (no mention of tool sharing).
The bootstrap file defs are not a secret and can be obtained. The reason for no disclosure agreements is for
PROIV to keep a track of those users who could be affected
by structural changes.
The structure of the bootstraps defs are not a good normalised structure with many attributes not used within
a file for a particular object. Searching for data/dependecies is not effecient and requires complex tools
to be written (yes I know us techies love writing monster updates that change everything!). It is not beyond the realms of possibility that we will offer the ability to store source within an RDBMS and we have investigated storage as XML the results of which would be great source control but appalling data navigation issues.
We are currently developing a replacement development environment for version 5.0. This will utilise an abstracted data model (similar approach to SL) including richer dictionary, object referencing and structural storage. This approach will provide a fast development environment (one of PROIV basic advantages - development speed) that will assist with reuse and management of code.
An API will be provided to allow manipulation of the source
data but has the advantages of file independence. The development environment will also allow the developer link
user tools into the development environment.
This environment project named VIP will beta trail in May
2001. I would also like to ask the community for features
that they would like concidered (on another thread).
Why do we need another development environment :-
To provide a flexible frame work to support new technolgies and PROIV features in an extensible and consistent manner and to ease the unsterstanding of the PROIV architecture to
newbies. Extensions will include XML, ActiveX and web tools
(ActiveX under development due to trial Sep 2001
XML output supported in 5.0)
To consolidate development into one unified environment.
To provide rapid application development and maintenace as an improvement to current environments and tools.
Posted 16 February 2001 - 09:34 AM
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?
Reply to this topic
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users