Jump to content

2009 Question File Format


MattG

Recommended Posts

A quick question about 2009. So what is the file extension. If someone has 2009 and I have 2008 can I open it or am I stuck like previous versions.

I really find that to be a bold statement if the new 12 month format is to go on. Saying that users who want to collaborate with other users need to upgrade every 12 months. The price point on vectoworks is nice. However autocad at least goes with the approach that the file format remains the same for 3 or so releases.

Link to comment

Good news & bad news: as I understand it (and I'm NOT a programmer), while the actual ".vwx" extension is the same for 2008 & 2009, 2009 uses a different file format (not sure exactly what that means). 2009 will open earlier versions (at least a couple of versions back) but 2008 will NOT open 2009 files. You can however EXPORT the 2009 file back to 2008, just like in all previous versions. There are (or may be) some translation issues, as the entire solids modeling kernal has been changed.

This, or similar protocol is pretty standard in the software industry: New versions always backwards compatible, but (almost) never forwards compatible...

Link to comment

The extension only has meaning to the OS as a way to link a document with the application that opens it. There would be no reason to change the extension in future releases unless you want to introduce a different but related product. This was the case of the extension change from MiniCad (mcd) to Vectorworks (vwx), which actually did not happen until VW 2008.

However, the file format of a major release needs to change in order to account for the improvements to the application. The format is an orderly stream of bits and a file can only be opened correctly by an application that knows how to decode the format. If the programmer allowed the opening of future versions, the application would most likely crash because it does not know how to handle the extra data in the format (e.g. VW 11 does not know about object opacity in VW 2008).

If the file format for AutoCad does not change, then to me, it means that the change was only cosmetic; either to the interface or the way it operates on the data.

Link to comment

However, the file format of a major release needs to change in order to account for the improvements to the application. The format is an orderly stream of bits and a file can only be opened correctly by an application that knows how to decode the format. If the programmer allowed the opening of future versions, the application would most likely crash because it does not know how to handle the extra data in the format (e.g. VW 11 does not know about object opacity in VW 2008).

Whilst file formats do need to cater for future requirements, there are may ways that formats can be forward and backward compatible between application versions.

Unless you are writing out records of fixed data structures, it is quite common for data to be translated to a file record format during read and write. It is highly unlikely that VW is doing this as the files are compatible between Mac snd PC. Meta data in the file, if part of the file format, can give information about each record in the file, and bringing data written by a newer application is often transparent. If new new features were written by the later version of the application were used, then the meta data would indicate to the older application that it could not understand the new data, and the data would simply be ignored. There however is no reason why a file should not be 360'd between old and new application version provided that the few file features are not used.

Another technique is for file formats to contain infrastructure for future releases. So if you knew that a future release would contain certain features, the file format could be adjusted advance of the new features being implemented. So when the new features were rolled out, no change in file format was necessary.

[technobabble]

I used this feature when I worked commercially in IT. It was a banking application used globally around the world and we needed to share information between branches/data centres and different application - the application would not be over 25 years old. It was a server/server application where different parts of the application was shared across different machines - it was way ahead of its time when it was first developed. The application data files contained records of the internal data structures, so were highly dependant on both processor architecture and application version. About 15 years ago, when we went from 32 bit to 64 bit, we put in the infrastructure to support 64 bit long before the actual migration to 64 bit hardware - the format of floating point numbers that we were using was deprecated on the 64 bit platform, however, whilst we did not store pointers so the change to 64 bit, we had to align variables on 64 bit word boundaries otherwise you would have ended up with the 64 bit application being slower than the 32 bit version - a variable straddling 2 different 64 bit words would require 2 fetch cycles. During each release, we would always provide a file conversion to reflect the change to any record structures, and a de-conversion if we needed to fallback the release. However because we pre converted the files for 64 bit, we could swap between 32 bit VAX and 64 bit Alpha processors at will, even within the same application where some parts of the application would run on a 32 bit VAX and other parts would run on 64 bit Alpha. The hardware mix was totally transparent, even to the application.

[/technobabble]

IMHO, if file formats are planned for and handled correctly, there should be little reason why data between different versions of application would need to be handled in a way that was not totally transparent to the user when sharing a file between 2 (or possibly more) consecutive version of an application. Unless someone is going to tell me that NNA only started working on 2009 after the release of 2008, they should have been in a position to incorporate changes for 2009 into the 2008 file structure. We would then be in a position to be able to share many files between 2008 and 2009 in a far more transparent way then they appear to be handled now.

This is especially important now that it looks like there will be a new version of VW on a yearly basis. Even if a file format change is released for a prior version by means of an SP, I personally think that it is important to be able to transfer files between consecutive versions pretty much transparently. Even if this means that having something as simple as a document preference that allows a file to be opened in its original format/saved in an earlier (or its unchanged original) format, without having to worry about exporting it everytime as a prior version.

Link to comment

One evolutionary trait that allowed Humans to proliferate was the unique ability of backwards <>forwards compatibility of information transference between generations and across tribal boundaries.

Think about what would've happened if each generation was isolated from all others by the inability to communicate effectively.

Every child would be born into a brave new world where prior knowledge was simply inaccessible.

Communication between parents and their children would lack sufficient efficacy to assure survival.

The development of high-level language skills made generational transmittance of knowledge possible.

Neanderthals apparently lacked this ability or failed to exploit it's potential.

And we know what happened to them when faced with competition from the more modern 360? file system called Cro-Magnon.

Indeed... those crafty Cros even managed to devise a system which allows members of future generations to assign values to actions of their ancestral generations ... without destroying the information in the process ... brilliant !

Link to comment

returning the to topic again :)

I think the issue here is not that simple actually. Remember that for 2009 the underlying modelling kernel has been changed from 2008. Also we are talking about geometry here not text or a database. This backwards compatibility argument rages across the entire MCAD sector where none of the main players offers ANY form of backwards compatibility.

How do the developers cater for changes in the underlying kernel? Different kernels build the same shapes from the same curves differently. Some operations like filleting and shelling will fail in one kernel and not in another, or even from version to version (it is no wonder the MCAD companies are pushing for non history modelling - one the huge issues when upgrading is to assure that older models rebuild in exactly the same manner and with the same results. With no history just the geometry has to work).

Link to comment

As far as I am concerned, if NNA supply an 'export as [former version]' here, then there is absolutely no reason why they cannot provide a transparent way to 360 files created in a former version. Yes, there will be functions that are in 2009 and not in 2008 that possibly cannot be exported, but, if you open a 2008 file in 2009, 2009 should write that file out in a way that is compatible with 2008. For files that use bits that cannot be exported correctly, a simple message saying that you have use a file that is incompatible with a previous version cab be display giving the use the option of what to do.

Many people will be working in a mixed version environment, especially people are working in workgroups. I personally feel that, and especially now that releases are 1 year apart, it is important to have the ability to open a 2008 file and save it (rather than having to think about exporting it) in the original file format that it was produced in.

If it can be exported as 2008 now, then VW should be able to know it was opened as a 2008 file and have the option to automatically save/export it as 2008 without the user having to think about it. Many other applications manage it, and not just text based ones.

[red rag to a bull]

Or maybe NNA do not trust their ability to export in a former version so put the onus on the user the take the risk of it possibly failing.

[/red rag to a bull]

I can personally see many people not upgrading simply because they work in a mixed environment and having to manually convert files is too much of a problem to manage.

Link to comment

Ian, most companies of any size choose not to upgrade every release cycle anyway for the simple reasons that projects are best completed in one version (which is the reason why Autodesk introduced subscriptions - to force users to pay even if they still used an old version).

Large scale Architecture design is on a par with enterprise level MCAD, where applications like CATIA are used. Enterprise level solftware like this is designed for each release to last maybe up to 10 years, with point releases. The file format is designed to be stable through that release cycle.

The problem is CATIA is a ?10k entry level package rising rapidly to ?20k per seat. Companies who make cars and aircraft recognise these issues. VectorWorks is a ?1.5k system max, with most in the UK being the Fundamentals at half that. The AEC market is just not used to paying enterprise level software pricing and all the benefits of file format that it offers.

Question:

Would you pay ?2000 a seat for VectorWorks Designer if the file format was backwards compatible for say 3 versions?

From the experience I have the answer would be a resounding no. As I said most firms I deal with skip a release or two or even three. The problems they have come when they have new hires or expansion and this needs new licenses. What tends to happen then is that project teams switch versions for the project.

So would I prefer NNA to divert development resources away from software improvements, bug fixes and interface changes to a re-structuring the file format to provide backward compatibility? No.

Link to comment

So would I prefer NNA to divert development resources away from software improvements, bug fixes and interface changes to a re-structuring the file format to provide backward compatibility? No.

Im not asking that. If they can already export in prior version format, they can save in that format automatically without user intervention. It does not require a file format change, just an intelligent save function and a file export that is 100% reliable - which it may or may not be already.

As far as I am concerned, the ability to transparently work in consecutive versions is a software improvement.

Link to comment

I also use autocad as it is what a lot of our clients here use. Why can I save something on my work machine that has release 2008 on it and open it on my home machine with 2007. I know the answer, it is that they somehow make the files compatible between releases within about 2 or 3 release cycles. I am just wishing that was something Vectorworks would consider.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...