Older LabVIEW installation disks

[Fabio Nicolas]

Hi, if somebody have the installation disks for the first LabVIEW versions, please share the disks images here or on Internet Archive (archive.org).

 

I am looking for Labview 1, Labview 2, Labview 3.1.1, Labview 4, Labview 5, Labview 6i.. I have an old computer running Windows 3.11 and Windows 95 and would like to install it just for fun, and also this kind os software is very rare and should be archived to never be lost.

[dadreamer]

I'm pretty sure, you can find LabVIEW 4 demo version on NI ftp server. I've also seen 3.x, 4.x and 5.x versions on macintoshgarden. As for the others, not sure, if they could be shared here as it still seems to be illegal, even though these versions are super dated and (almost) nobody uses them for production now. Well, I do have some, but I'm going to see the admins position about this.

P.S.: I too like this kind of fun and I'm seeking for some versions. Still couldn't find 1.x to try it in some early Mac emulator. Interested in BridgeVIEW distros as well and maybe in some old toolkits like Picture Control Toolkit.

[Rolf Kalbermatter]

I used to have a whole box of disks and CD ROMs of old versions, though nothing before 2.2.1 which was Mac Only. But after 30 years and 3 major relocations, almost all of this has eventually ended up in the big round archive called trash bin. It's just not practical to hold onto these forever, and that stuff actually weights quite a bit altogether. Not fun to carry around and also not fun to fill up storage space (that I seem to always have not enough).

[hooovahh]

I think the oldest I have is 7.0 or 7.1 in physical form.  These boxes of old stuff just look cool to me so I have them displayed in my office along with a few LabVIEW books, and boxes of older software like Windows 3.1.  I do wish I had more just to display and show off.

[dadreamer]

Since my last post somebody has uploaded LV 2.2 to macintoshgarden. I didn't have time to try it though. This and last year I have also seen a screenshot of LV 1.x in some Mac emulator at NI forums. Maybe that guy even would be willing to share his archive for historical reasons, if properly asked.

2 hours ago, Rolf Kalbermatter said:

the big round archive called trash bin

So no longer much of a reason to request anything, I assume? 5 or so years back I was planning to ask for Picture Control Toolkit (seen your posts at NI forums), but something distracted me and that did never happen.  Now I'm even unsure I'm ready to waste time for that old tech.

[HYH]

Hi

I found two original floppies with a Demo version of 2.5.1 from 1992. I hope NI won't mind I share them. They were handouts to prospective buyers of LV back then.

LV crashed immediately with a divide by zero in WfW 3.11.

LV also caused a Win386 error in Win 95, which could be ignored. So here is the glorious screen image :

The computer is from 2000. The CPU is a Pentium Pro.

Regards

LVD251D1.zip LVD251D2.zip

[dadreamer]

I would post here a link to LabVIEW 2.5.2 distro as well, but I don't know if I'm allowed to. I found it in the web archive years ago, there was no registration number or any owner's information. It was just LabVIEW + Advanced Analysis Library, without extra toolkits. Latest OS where it works is Windows 98 (with few non-fatal errors). It should have worked with some hardware too as daqdrv, gpibdrv and serpdrv plus ther VI wrappers are included, but as I've been running it in a VM, no such tests have been done.

Even in such a minimalistic form it was quite an interesting version. For example, the cintools folder did contain more sources than in later versions. Many internal Managers, such as Dialog Manager or Window Manager, were exposed there. Some of them still exist in the modern code base, although NI has started to clean up the obsoleted functions few years ago.

Also this is the only Windows version with most Mac OS relicts, e.g. Size Handle, Handle Peek, Handle Poke (I mentioned them on the other side). In theory those thin wrappers might be expanded onto many other Memory Manager functions, eliminating the need of calling them through CLFNs. But they were simply removed from the palettes and abandoned.

[HYH]

Hi again

Fortunately I didn't have to make a living using LabVIEW 2. It was just a proof of concept and I first jump'ed in on LabVIEW 3. It was a splendid version to interface to the mighty NI-DAQ. Some really powerful data acquisition systems could be made then running on WfW 3.11. NI's claim to fame is really NI-DAQ and less LabVIEW.

But I don't miss the countless hours spend on configuring memory managers like Quarterdeck's and manually setting I/O addresses and Interrupts and DMA channels on dumb ISA boards.

Regards

 

[Rolf Kalbermatter]

On 8/5/2023 at 1:36 PM, dadreamer said:

I would post here a link to LabVIEW 2.5.2 distro as well, but I don't know if I'm allowed to. I found it in the web archive years ago, there was no registration number or any owner's information. It was just LabVIEW + Advanced Analysis Library, without extra toolkits. Latest OS where it works is Windows 98 (with few non-fatal errors). It should have worked with some hardware too as daqdrv, gpibdrv and serpdrv plus ther VI wrappers are included, but as I've been running it in a VM, no such tests have been done.

Even in such a minimalistic form it was quite an interesting version. For example, the cintools folder did contain more sources than in later versions. Many internal Managers, such as Dialog Manager or Window Manager, were exposed there. Some of them still exist in the modern code base, although NI has started to clean up the obsoleted functions few years ago.

Also this is the only Windows version with most Mac OS relicts, e.g. Size Handle, Handle Peek, Handle Poke (I mentioned them on the other side). In theory those thin wrappers might be expanded onto many other Memory Manager functions, eliminating the need of calling them through CLFNs. But they were simply removed from the palettes and abandoned.

Those handle functions only really worked on the Mac, since they were actually creating native MacOS handles, not the LabVIEW own flavor of them that was a sugar layer around the rather arcane Macintosh memory manager calls. Yes the Macintosh memory manager was famous for being not high performant and quite  crash sensitive. It worked for most Macintosh applications sort of, but LabVIEW really was considered a stress test for it. It was also regularly stressing the Macintosh Programmer Workshop C compiler that the LabVIEW team used to build the product. It was quite a regular happening that NI had to request Apple support to build a new version of it with bigger symbol table space, in order for the compiler not to fatally crash during build of some of the larger C source files.

When the multiplatform version was started some of the real cracks in the LabVIEW team actually prefered to develop and debug on the Sun Solaris version of LabVIEW, since the compiler and debugger tools where a lot more powerful on there, even though everything was in fact all command line based.

And yes LabVIEW 2.5.x was Windows 3.1 only. It was never tested nor build to run under Windows 95 or later, which would have been very difficult considering that it was released in fall 1992. The first version supporting Windows 95 natively was AFAIK LabVIEW 4.0. LabVIEW 3.1 or thereabout did however have a version that could be installed on Windows NT 3.1.

 

Edited August 7 by Rolf Kalbermatter

[HYH]

Hi

Anybody interested in the history of LabVIEW and NI could start by reading by Jeff Kodosky's rather long entry published from 2020 :

ACM Reference Format: Jeffrey Kodosky. 2020. LabVIEW. Proc. ACM Program. Lang. 4, HOPL, Article 78 (June 2020), 54 pages. https: //doi.org/10.1145/3386328

It is 54 pages long and includes a proper index. Pitty NI stopped making quality documents/manuals like this after ~ 2008.

There are also references on LabVIEW Wiki :

"History of LabVIEW" presented by Jeff Kodosky, the "Father of LabVIEW," as he looks back at the creation of graphical programming and shares fundamental programming concepts vital to the next 25 years of graphical system design for meeting the most demanding application challenges. (NIWeek 2011)

"Future of LabVIEW" presented by Jeff Kodosky, the "Father of LabVIEW," talks about the beginnings and future of LabVIEW. (NIWeek 2016)

"Evolution of LabVIEW" presented by Jeff Kodosky, the "Father of LabVIEW," discusses the early beginnings of LabVIEW and how it has evolved into what it is today. (NIWeek 2017)

"LabVIEW History & Timeline | Jeff Kodosky & Dr Truchard Interviews" by ElectronicsNotes, LabVIEW was first launched in 1986, since then, it has been developed to provide many new facilities and keep up with the needs of the latest engineering requirements from development and research through to control, monitoring and data acquisition.

Regards

 

 

[hooovahh]

8 minutes ago, HYH said:

"Future of LabVIEW" presented by Jeff Kodosky, the "Father of LabVIEW," talks about the beginnings and future of LabVIEW. (NIWeek 2016)

This video appears to be missing.  But otherwise lots of good resources.

[dadreamer]

I'd add here Rolf's excellent revelations on interfacing external code to LabVIEW

External Code in LabVIEW, Part1: Historical Overview

External Code in LabVIEW, Part2: Comparison between shared libraries and CINs

External Code in LabVIEW, Part3: How to use the Call Library Node properly to ease multi platform support

[Robert Maskell]

Hi Guys,

 

Don't know if you are still looking.  I have all the old LabVIEW 1 floppies and the original LV1 demo disk set. 

[Robert Maskell]

Still looking for more.  LV2.5.1, 2.5.2 Win, LV 3 win, mac and sun. libraries etc and much much more all the Bridgeviews also plus LabWindows 1 and 2

[dadreamer]

On 11/19/2023 at 9:24 AM, Robert Maskell said:

LabWindows 1 and 2

I have seen LabWindows 2.1 on old-dos website. Don't know if it's of any interest for you tho'. As to BridgeVIEW's, I still didn't find anything, neither the scene release nor the customer distro. Seems to be very rare.

On 11/19/2023 at 9:17 AM, Robert Maskell said:

I have all the old LabVIEW 1 floppies and the original LV1 demo disk set. 

Sure some collectors out there would appreciate, if you archive them somewhere on the Wayback Machine. 🙂

[Mefistotelis]

When I was still at university, I've heard an anecdote about NI once releasing complete source code with a specific LabVIEW version, by mistake. I think I later saw a confirmation on one of LV-related forums (not sure if this one). But after a quick search, I can't find it.

 

Anyone knows more about this? I'm not really interested in working on LV sources, but would be interesting to just compile that with a modern toolchain.

Looking at the releases I have:

* cintools-2_5 has a few ASM files, including assembly source for LVRT. But doesn't look like the whole thing - there's 400k of `.asm` and `.h` files in total.

* cintools-3 has a header (extcode.h) which is a concatenation of all headers from LV - so there's 327k of headers. No sources though.

* cintools-6_0 only has standard cintools headers, but there are lots of `.lib` files included (static libraries are a collections of .obj files). So no source code, but there seem to be enough `.obj` files for the whole labview - 1.2M in total

the releases after 6.0 don't seem to have much interesing stuff in them. And considering when I was at university, the rumored release must have been not newer than v8.0.

[Rolf Kalbermatter]

Never heard anything about the complete source code being accidentally released. And I doubt that actually happened.

They did include much of the headers for all kinds of APIs in 2.5 and even 3.0 but that are just the headers, nothing more. Lots of those APIs were and still are considered undocumented for public consumption and in fact a lot of them have changed or were completely removed or at least removed from any export table that you could access.

Basically, what was documented in the Code Interface Reference Manual was and is written in stone and there have been many efforts to make sure they don't change. Anything else can and often has been changed, moved, or even completely removed. The main reason to not document more than the absolutely necessary exported APIs is two fold.

1) Documenting such things is a LOT of work. Why do it for things that you consider not useful or even harmful for average users to call?

2) Anything officially documented is basically written in stone. No matter how much insight you get later on about how useless or wrong the API was, there is no way to change it later on or you risk crashes from customer code expecting the old API or behavior.

Those .lib libraries are only the import libraries for those APIs. On Linux systems the ELF loader tries to search all the already loaded modules (including the process executable) for public functions in its export tables and only if that does not work will it search for the shared library image with the name defined in the linker hints and then try to link to that.

On Windows there is no automatic way to have imported functions link to already loaded modules just by function name. Instead the DLL has to be loaded explicitly and at that point Windows checks if that module is already loaded and simply returns the handle to the loaded module if it is in memory. The functions are always resolved against a specific module name. The import library does something along these lines and can be generated automatically by Microsoft compilers when compiling the binary modules.

HMODULE gLib = NULL;

static MgErr GetLabVIEWHandle()
{
    if (!gLib)
    {
        gLib = LoadLibraryA("LabVIEW.exe");
    	if (!gLib)
        {
            gLib = LoadLibraryA("lvrt.dll");
            if (!gLib)
            {
                /* trying to load a few other possible images */
            }
        }
    }
    if (gLib)
        return noErr;
    return loadErr;
}

MgErr DSSetHandleSize(UHandle h, size_t size)
{
    MgErr (*pFunc)(UHandle h, size_t size);
    MgErr err = GetLabVIEWHandle();
    if (!err)
    {
        pFunc = GetProcAddress(hLib, "DSSetHandleSize");
        if (pFunc)
        {
            return pFunc(h, size);
        }
    }
    return err;
}

This is basically more or less what is in the labview.lib file. It's not exactly like this but gives a good idea. For each LabVIEW API (here the DSSetHandleSize function) a separate obj file is generated and they are then all put into the labview.lib file.

Really not much to be seen in there.

In addition the source code for 3.0 only compiled with the Apple CC. Metroworks for Apple, Watcom C 9.x and the bundled C Compiler for SunOS. None of them ever had heard anything about 64 bit CPUs which were still some 10 years in the future. And none was even remotely able to compile even C89 conformant C code. LabVIEW source code did a lot of effort to be cross platform, but the 32-bit pointer size was deeply engrained in a lot of code and required substantial refactoring to make 64-bit compilation possible for 2009. The code as is from 3.0 would never compile in any recent C compiler.

Edited November 23 by Rolf Kalbermatter

[ShaunR]

13 hours ago, Rolf Kalbermatter said:

On Linux systems the ELF loader tries to search all the already loaded modules (including the process executable) for public functions in its export tables and only if that does not work will it search for the shared library image with the name defined in the linker hints and then try to link to that.

And that's another big reason why ECL won't be available in Linux. It was ok when it used the NI binaries but the switch to standard OpenSSL binaries means that the CLFN usually loads system wide binaries (even if you define a path) and there is no way for LabVIEW to use "RTLD_DEEPBIND".

[Mefistotelis]

Thanks @Rolf Kalbermatter. You're right about the `.lib` files - just looked at one and it's just a collection of stubs. It's not for dynamic symbol loading, instead it calls `CallLVRT`, giving it a static struct as first parameter - this first parameter contains the symbol name to actually call. There's more than a thousand of symbols in that `.lib` and all of them do that.

For compiling the LV 2.5 ASM - it would require some minor changes, but not the arch conversion - toolchains today still have `-m32` or `-arch i386` or other parameters to switch to 32-bit, and PC OSes, at least for now, offer 32-bit user space.

(I'm actually curious about compiling 64-bit app with 32-bit sub-module inside.. seen people experimenting with code segment selector to get to 32-bit mode. Requires mmapping any memory to be accessible in 32-bit space. Not sure if it works outside Linux though.)

Still, it's just ASM - with todays disassembly tools (and some minimal manual work) I can get compilable ASM for any version of LV, the only difference would be lack of comments and lack of names for static symbols.

 

[Rolf Kalbermatter]

But those ASM source code files are just some glue code that were initially needed for linking CINs. CINs used originally platform specific methods to use object files as loadable modules. They then had to be able to link back to the LabVIEW kernel to call those manager functions and there was no easy method to do that in standard C. CallLVRT was the calling gate through which each of those functions had to go through when trying to call a LabVIEW manager function. In order to reference the internal LV function table required at that point assembly code to work and there were also some initialization stubs that were required. These assembly files were normally not really compiled as there were some link libraries too that did this, but I guess with 2.5, the release was a bit rushed and there were definitely files released in the cintools directory that were a bit broader than strictly needed.

With LabVIEW 5 for 32-bit platforms (2000/95/98/NT) NI replaced this custom call gate to the LabVIEW kernel through a normal module export table. On these platforms the labview.lib link library replaced the CallLVRT call gate through a simple LoadLibrary/GetProcAddress interface. With LabVIEW 6i, which sacked Watcom C and the according Windows 3.1 release, the need for any special assembly files at least for the Windows platform was definitely history.

There were strictly speaking 3 types of external code resources. CINs which could be loaded into a CIN node, LSBs which were a special form of object file that could be loaded and linked to by CINs (it was a method to have global resources that were used by multiple CINs) and then there were DRVRs which were similar to CINs but specifically meant to be used by the Device interface nodes. DRVRs were never documented for people outside NI but were an attempt to implement an interface for non-Macintosh platforms that resembled the Macintosh Device Manager API. In hindsight that interface was notoriously troubled. Most Macintosh APIs were notorious for exposing implementation private details to the caller, great for hackers but a total pita for application developers as you had to concern yourself with many details of structures that you had to pass around between APIs. And when Apple changed something internal in those APIs it required them to make all kinds of hacks to prevent older applications from crashing, and sometimes they succeeded in that and sometimes they did not! 😀

serpdrv was a DRVR external code resource that translated the LabVIEW Device Interface node calls to the Windows COMM API.

Edited November 24 by Rolf Kalbermatter