Leaderboard

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.

The problem with test stand is it tries to be all things to all people. IMO, simplifying is best. I haven't used TS for quite a while but when I did, I offloaded all tests to LabVIEW and just used it basically as a script. I had a VI with command/response capabilities (via TCPIP) which meant that TS sequences were a list of operations and just sent strings to execute tests and take measurements. One nice side-effect of the TCPIP meant that you could also execute tests remotely so an operator didn't even have to be sitting next to the machine the tests were running on (quality engineers loved that they could run tests and calibrate from their desks instead of going out to the machine).