LV 2016 Known Issue 583670. Can I really no longer build for Win7 after I install?

[pallen]

Just having a look last night at known issues etc. before installing the latest version of LabVIEW. 

This particular issue jumped right out.  Myself and many of my customers still use Win7.  If true, this issue will force me to keep LV 2016 on a separate dev machine from all my other versions. 

The article specifies Windows versions 7 RTM and older.   I am unsure if there is a "version" of Windows 7 that is considered "newer" than RTM. ( release to manufacturing )  So far I have not found one.

Can anyone confirm this issue?

http://www.ni.com/product-documentation/53135/en/#583670_by_Category

If LabVIEW 2016 is installed, installers built in any version of LabVIEW will not work on Windows 7 RTM and older
See the following KB for details: http://digital.ni.com/public.nsf/allkb/93EC6C4911C6B72E86257FAA0067CC79?OpenDocument

Workaround: Do not install LabVIEW 2016 on a computer which builds installers for Windows 7 RTM, Windows Vista, Windows XP SP3, and older.

[WNM · Accepted solution]

Windows 7 SP1 can use it.  But it is a bit worse than  you've discovered, at least in my opinion. Installing LabVIEW 2016 breaks complicates the ability to build functional installers for these older operating systems and in fact it does so for previous versions of LabVIEW that might also be installed on the machine other than LV2016 since they all seem to use the same (most recently installed) version of the application builder. See this discussion for more information and a somewhat inconvenient work-around. LabVIEW 2014 installer points to wrong minimum OS

But wait, it gets worse.  If you happen to install the August 2016 device drivers, and if your application happens to need any of those drivers (e.g. VISA) to work, then the application you build will not run on the disallowed older operating systems.  The driver disks contain this warning in their README.HTML file:

"NI Device Drivers Version 16.8 Drops Support for Microsoft Windows 7 RTM, Windows Vista, Windows XP, and Windows Server 2003"

"With this release, NI Device Drivers drops support for Microsoft Windows 7 RTM (with no service pack), Windows Vista, Windows XP, and Windows Server 2003. NI Device Drivers version 16.8 and later will not install or run on an unsupported OS. You cannot deploy or distribute applications that use NI Device Drivers version 16.8 and later on an unsupported OS. Additionally, after installing NI Device Drivers version 16.8, you cannot use any installers built on this computer with any version of LabVIEW, LabWindows™/CVI™, NI TestStand™, or Measurement Studio on an unsupported OS."
"For more information about the changes to our OS support for 2016, refer to KB 79UC78LS, Why Does my LabVIEW, LabWindows/CVI, Measurement Studio, or TestStand Built Installer Fail on Windows XP/Vista and Server 2003."

I neglected to unearth these facts before installing LabVIEW 2016 and the August 2016 drivers and then, when I tried to use LabVIEW 2015 to build an application for use on an old stand-alone XP lab test-support machine, I first discovered that the installer refused to run on the target machine and when I manually installed the application, I discovered that it would not run with the VISA drivers already installed on the target machine. Trying to install the August 2016 VISA driver was a no-go because the new 2016 NI VISA installer would not run on XP.

SInce I need to support several of these older stand-alone XP machines in our test environment (DOE, LLNL) I needed to get back to a place where I could build functional applications for them. I opened a service ticket with NI to find out how to undo the LV 2016 installation and the August 2016 driver installation and, in a nutshell, was told that it was irreversible.  The 2016 updates so deeply integrate themselves into the NI software system and burn so many bridges to recovery that that cannot be uninstalled without uninstalling all NI software on the development machine.  Eventually I resigned myself to this fact and, after making sure I could still find all the installers for all the versions (7.1.1, 8.0, 2011, 2012, 2013, 2014 & 2015) of LabVIEW that I had on the development system, I uninstalled all NI products from the system, removed all NI files from their normal disk locations and scrubbed all mention of NI from the registry (this is on Windows 7 Enterprise SP1).  When I went to reinstall, the v8.0 installer crashed and 2011 & 2012 had site-licensing problems (the others went in OK). Since back in mid-July I had moved my system disk from a HDD to a SDD I decided that the best way to recover what I had before NI-2016 was to copy everything on the SDD that had changed since that disk-swap date and then reinstall the slightly-stale HDD into the PC since it pre-dated the NI-2016 fiasco. That has seemed to work from a NI software standpoint, but I'm still getting the HDD beat back into shape for all the other files and programs. When it is 100% good again, I'll again clone it over to the SDD and get that going.  There's nothing like spending two weeks recovering from a new and improved NI update.

I intend to stay far away from the NI software and driver updates for the foreseeable future (as long as I have older systems to support) because the new software just does not have enough improved functionality to lose out on the capability to support these older systems and my organization is not about to discard those older systems as long as they are adequately performing their duties.  I have turned off the NI Update Service to be sure my system remains stable in it current state.

My advice to anyone contemplating these or any other major NI software updates is to do a full image backup of your system (any disks with NI software installed) prior to the update.  Read all the README files closely before the update and understand what they say. After the update, immediately test the old and new NI software to be sure that it still does everything you need it to do so that if you find that you need to flush it off your system, the image backup needed to do so is still very fresh.

[RTSLVU]

---

@WNM wrote:

Windows 7 SP1 can use it.  But it is a bit worse than  you've discovered, at least in my opinion. Installing LabVIEW 2016 breaks complicates the ability to build functional installers for these older operating systems and in fact it does so for previous versions of LabVIEW that might also be installed on the machine other than LV2016 since they all seem to use the same (most recently installed) version of the application builder. See this discussion for more information and a somewhat inconvenient work-around. LabVIEW 2014 installer points to wrong minimum OS

But wait, it gets worse.  If you happen to install the August 2016 device drivers, and if your application happens to need any of those drivers (e.g. VISA) to work, then the application you build will not run on the disallowed older operating systems.  The driver disks contain this warning in their README.HTML file:

"NI Device Drivers Version 16.8 Drops Support for Microsoft Windows 7 RTM, Windows Vista, Windows XP, and Windows Server 2003"

"With this release, NI Device Drivers drops support for Microsoft Windows 7 RTM (with no service pack), Windows Vista, Windows XP, and Windows Server 2003. NI Device Drivers version 16.8 and later will not install or run on an unsupported OS. You cannot deploy or distribute applications that use NI Device Drivers version 16.8 and later on an unsupported OS. Additionally, after installing NI Device Drivers version 16.8, you cannot use any installers built on this computer with any version of LabVIEW, LabWindows™/CVI™, NI TestStand™, or Measurement Studio on an unsupported OS."
"For more information about the changes to our OS support for 2016, refer to KB 79UC78LS, Why Does my LabVIEW, LabWindows/CVI, Measurement Studio, or TestStand Built Installer Fail on Windows XP/Vista and Server 2003."

I neglected to unearth these facts before installing LabVIEW 2016 and the August 2016 drivers and then, when I tried to use LabVIEW 2015 to build an application for use on an old stand-alone XP lab test-support machine, I first discovered that the installer refused to run on the target machine and when I manually installed the application, I discovered that it would not run with the VISA drivers already installed on the target machine. Trying to install the August 2016 VISA driver was a no-go because the new 2016 NI VISA installer would not run on XP.

SInce I need to support several of these older stand-alone XP machines in our test environment (DOE, LLNL) I needed to get back to a place where I could build functional applications for them. I opened a service ticket with NI to find out how to undo the LV 2016 installation and the August 2016 driver installation and, in a nutshell, was told that it was irreversible.  The 2016 updates so deeply integrate themselves into the NI software system and burn so many bridges to recovery that that cannot be uninstalled without uninstalling all NI software on the development machine.  Eventually I resigned myself to this fact and, after making sure I could still find all the installers for all the versions (7.1.1, 8.0, 2011, 2012, 2013, 2014 & 2015) of LabVIEW that I had on the development system, I uninstalled all NI products from the system, removed all NI files from their normal disk locations and scrubbed all mention of NI from the registry (this is on Windows 7 Enterprise SP1).  When I went to reinstall, the v8.0 installer crashed and 2011 & 2012 had site-licensing problems (the others went in OK). Since back in mid-July I had moved my system disk from a HDD to a SDD I decided that the best way to recover what I had before NI-2016 was to copy everything on the SDD that had changed since that disk-swap date and then reinstall the slightly-stale HDD into the PC since it pre-dated the NI-2016 fiasco. That has seemed to work from a NI software standpoint, but I'm still getting the HDD beat back into shape for all the other files and programs. When it is 100% good again, I'll again clone it over to the SDD and get that going.  There's nothing like spending two weeks recovering from a new and improved NI update.

I intend to stay far away from the NI software and driver updates for the foreseeable future (as long as I have older systems to support) because the new software just does not have enough improved functionality to lose out on the capability to support these older systems and my organization is not about to discard those older systems as long as they are adequately performing their duties.  I have turned off the NI Update Service to be sure my system remains stable in it current state.

My advice to anyone contemplating these or any other major NI software updates is to do a full image backup of your system (any disks with NI software installed) prior to the update.  Read all the README files closely before the update and understand what they say. After the update, immediately test the old and new NI software to be sure that it still does everything you need it to do so that if you find that you need to flush it off your system, the image backup needed to do so is still very fresh.

---

"F" ME! I still have to support and deploy LabVIEW on XP machines in the lab.

I am so far beyond screwed that the light from Screwed will take a thousand years to reach me.

Thanks NI.

[pallen]

Can anyone confirm no build issues with Windows 7 SP1? 

[WNM]

---

@pallen wrote:

Can anyone confirm no build issues with Windows 7 SP1? 

---

You can develop, use, build and deploy to Win7 SP1 without problem using 2016 but that's the oldest Windows OS that it supports.

[Matthew_Kelton]

I really think NI dropped the ball on this one.  Anytime they decide to drop support for an OS, there should be a big warning message before installation.

When the install will drop support for an OS across the board of all LV versions installed, it should be a big red warning box before installation.  Especially when they claim you have to uninstall everything in order to get it back.  (Of course, I am not sure I believe them on that, either, since that is their solution for a lot of problems that do not require it).

[Hooovahh]

This is sorta a big deal, and sorta not.  So I upgraded to 2016, and the August 2016 device drivers without ever knowing that a bunch of OS support was dropped.  This table hasn't been updated yet, but if it does get updated then it will be the first time that a new release of LabVIEW dropped more than one version of Windows support in a consecutive release dropping XP, Vista, and even SP0 of Windows 7.  With the exception of 7.1 which dropped 98 and ME from 7.0, and 98 and ME were quite similar.

http://digital.ni.com/public.nsf/allkb/B972242574D4BB99862575A7007520CB

The reason this isn't as big of a deal is because Windows 7 SP1 is still supported for development and builds.  If you are on Windows 7 SP0, then this is another reason to take the free upgrade.  If you are on Vista, well I'm not sure why you are but you should upgrade.  I've only ever seen one Vista computer in a work environment at the multiple companies I've worked at through the years and it wasn't for development or deployment of LabVIEW.  If you are on XP, then you are probably running some older legacy program, possibly on older hardware, and upgrading is not something you will likely want to do.

So yes this should be more in your face during the install, and yes it is going to cause issue (sounds like it already has), but maybe this is another reason why developers should be using sandboxed VMs.  I know I don't use them for every project but something like this makes me want to.  Also there is the fact that NI has their NI Update Service which usually shows newer version of NI drivers you can install and it makes it seem like theres no issue and compatibility problem at all.  That is until you need to build a program for XP and all the sudden you can't because a driver update went through when you weren't aware of the consequences.

I've never been on the last supported OS for the newest version of LabVIEW I use so that is a bit odd.  I think the overwhelming majority of office computers today are Windows 7.  And if you are desiging a new test system I think Windows 7 will still probably be your OS, with Windows 10 being an option.

I don't know I have a lot of opinions but I think we can all agree NI could have handled this a little better.

[Alexander_Sobolev]

Overwhelming majority of computers is on Win7, but if there is at least one winXP PC that has to be supported, then it is easier not to upgrade. Otherwise you have to jump jump between machines/versions and remember not to open files in wrong LV version. Compeletely agree with WNM that changes in new versions (at least 3-4) do not justify upgrade. It has to be done when it has to be done, not when update is available. At least we are working with labs, not pure offices, they are conservative because their upgrades are usually much-much-much more expensive than just pressing Windows/Labview check for updates button. 

[WNM]

---

@Hooovahh wrote:

I've only ever seen one Vista computer in a work environment at the multiple companies I've worked at through the years and it wasn't for development or deployment of LabVIEW.  If you are on XP, then you are probably running some older legacy program, possibly on older hardware, and upgrading is not something you will likely want to do.

---

Just to be clear, not only are you prevented from use of 2016 for upgrading/development on, or deployment to, these older machines but you are also prevented from deployment or updating of any old or new executable using any older version of LabVIEW to these older machines.

For example, if you had an old XP executable to read and display whatever came into a hard-coded COM1 built using LabVIEW 2011, if after this update you tried to again use 2011 to rebuild it to instead use COM2, then it would first fail to install and, if you then manually installed it, it would fail to run.

I'll be the first to admit that these older machines should not be front-line development machines but just because they are no longer network connected does not render them valueless. Around here many of them get pushed down to much more mundane operation of test stands and so forth.

With this version/update NI has effectively cut off all support for a large class of older hardware. The sad part is that I don't think it was really necessary. Sure they could say that they are not going to develop new drivers for old hardware but I think, if they had wanted, they could have let the old drivers/support for the old hardware/OS continue to ride along. After all, it's not like they are shy about growing the sizes of their installation images. What's a few hundred megabytes more (if that much) among the many hundreds of gigabytes that are now offered. I'll bet there are more of us who have use for the older support that was pulled than we have for much of the other stuff found on the install disks these days.

I personally think in this respect NI is out of touch with their customer base. 

[Thoric]

---

@WNM wrote:

---

@Hooovahh wrote:

I've only ever seen one Vista computer in a work environment at the multiple companies I've worked at through the years and it wasn't for development or deployment of LabVIEW.  If you are on XP, then you are probably running some older legacy program, possibly on older hardware, and upgrading is not something you will likely want to do.

---

Just to be clear, not only are you prevented from use of 2016 for upgrading/development on, or deployment to, these older machines but you are also prevented from deployment or updating of any old or new executable using any older version of LabVIEW to these older machines.

For example, if you had an old XP executable to read and display whatever came into a hard-coded COM1 built using LabVIEW 2011, if after this update you tried to again use 2011 to rebuild it to instead use COM2, then it would first fail to install and, if you then manually installed it, it would fail to run.

---

That's why sandboxing is an important strategy when supporting multiple platforms and LabVIEW versions.

I use virtualised OS's for each version of LabVIEW I develop with, never do I install two on the same machine (Actually, I have done or twice, and got stung each time - lesson finally learned). So LV2016 goes onto a clean virtualised OS and doesn't impact on my other development environments.

Besides, if you have multiple installs of LabVIEW on one machine, how can you say that you can still support development of your legacy code? With the revisions to DAQ/VISA etc. you'll be working in a different environment every time you approach your legacy source code. It really helps to have everything isolated - legacy software in a dedicated environment that isn't affected by other project work.

That said - I'm astonished at this drop in support from NI. I maintain a couple of XP machines with old LV2011 code, and thankfully I have the source and LV installations cloned into a virtual OS so I know they're protected from other LabVIEW work, but this is the first time I've actually felt that the potential to upgrade would be a compromise.

Thanks for the alert to this issue.