A Lil bit of History ..

[swatts]

Morning LabVIEW History Lovers,

I was preparing for a presentation and digging around in our archives down in the SSDC crypt and managed to find something quite impactful to our LabVIEW world.

Cast your mind back to 1996 (1997 or 1998, I struggle with time)

This little system was used for calibrating 3 Density transducers, it was essentially 3 systems running asynchronously, but sharing hardware.

Jonny Conway and I were deep in our masters degree and were sharing software design concepts (Jonny had already sussed LCOD from a coupling and cohesion perspective, I was the student).

We decided to use this project to exercise our ideas and try and see if 2 different programmers could build a system with a similar design, if they had learnt similar design techniques.

LabVIEW 5 - did not have many of the things that make our lives easier like event structures, Queues, classes and we didn't know about Type Defs.. I don't think it had undo either, but I might be wrong on that... I'm sure the comments will tell me.

We put all VIs in a LLB much to consternation of the small LabVIEW world we lived in. (LabVIEW programmers mainly talked to each other via comp.lang.labview and LTR in those days!)

Anyways the main design challenge was the shared resources of the hardware and the screen. In our masters we had delved into UI design, OOP and design patterns and I had messed with Visual Basic and it appeared that queues were used everywhere, and yet there wasn't a queue mechanism in LabVIEW... so we rolled our own (it also worked as a stack).

Here it is described in our book (A Software Engineering Approach to LabVIEW)

This is where the history may be up for debate, but our book was written in 2001 and early manuscripts were sent out. One of the early reviewers was Mr Stephen Mercer, who saw us struggling and came up the far more efficient Queue primitive. (I think our book also got him thinking about OOP, but that's another story and very open to correction)

Hopefully I have told it accurately, remembering the past is not a key skill of mine.

Lots of Love

[gobshite]

> Mid to late 1999 I believe.

5.0 was released in February 1998. It had actually a whole bunch of new features. From the top of my head:

- Undo, 10 steps default but you could configure it higher in the configuration, however in those days 128 MB in computers were still not standard, so you had to be careful with that.

- Multithreading, LabVIEW introduced in addition to its own already present internal cooperative multithreading (so called asynchronous nodes could suspend themselves and let the LabVIEW scheduler do other things in the meantime) also native preemptive multithreading if the underlaying platform supported it (Mac Classic and Windows 3.1 did not). Windows NT, Sun Solaris, HP Unix and PowerMAX did.

- fully native TCP/IP nodes

- ActiveX support

- native VI Server interface instead of a very limited bolted on solution through a CIN

- there were rumors of an actually working unofficial version for Linux, but I only saw that around 7.0 times for real

5.1.1 was released begin 2000 and until 7.1.1 in November 2004 one of the most stable versions ever released

The actual Version Control support in LabVIEW was not bad because of how it was integrated in LabVIEW (although it wasn't anything that really stuck, since Tortoise SVN with Windows Explorer integration actually simply worked better). The reason that Version Control majorly sucked was the fact that the default provider was Microsoft Visual Source Safe. Visual Source Safe was the worst version control system you could imagine. It was entirely build around the checkout - checkin workflow, which in itself was quite cumbersome for casual use, but the worst thing was that committing your sources to Visual Source Safe regularly could end in a form of FINO (First In, Never Out) as it occasionally could eat up commitments and simply loose them in its internal database. For a Version Control System that is pretty much a KO criteria and Microsoft eventually let it silently die.

The alternative was Perforce, which NI used themselves internally. It used the same checkout - checkin workflow but did work reliable. But it was to expensive for casual use as Version Control System.

There were some Version Control Plugin adapters for SubVersion and others from that time, either through a Microsoft Version Control API adapter or driectly through a LabVIEW plugin adapter, but they all lacked from the same problem. Maintenance and support costs time and money, but most users wanted a free solution, as in free beer.

[swatts]

That's good service in anyone's book.

Apart from the date, my rendition is pretty accurate isn't it?

[gobshite]

Tis

[thols]

We had Undo in LV5, but only very few steps (how many?). So what I did sometimes was save temporary versions of the VI now and then and use them as undo-steps. 

Th version control at this time for us was files with version in their names. But we started using NIs version control program/feature at this time, whatever that was called. Because it was included and we payed for it so it must be good, right... But it was horrible and dangerous.

[swatts]

LV 5 was really the turning point for me, I personally thought 4 was great but not really capable enough for production code (in aerospace).

But in those days of perpetual licensing we didn't upgrade for years... The cheapest way for a company to use LabVIEW was buy a license with no SSP and just keep it. So 5 would have been new to us, but not new...