LabVIEW
database tools labview 2015 don%27t work on 64-bit windows 10
@ijustlovemath wrote:Bob, that's the issue. Why would all the tools not be on the arguably more prevalent and popular architecture?
Open task manager. Go to the tabs page. Except for system processes, I bet there at least as many, if not more, processes with *32 after them, which indicates 32 bit processes. It may be the prevalent architecture, but by no means the more prevalent application mode. There's no good reason why any more, but look how long it took MS to ditch Windows on DOS!
[edit]
I like @RavensFan's post better.
[/edit]
@ijustlovemath wrote:Bob, that's the issue. Why would all the tools not be on the arguably more prevalent and popular architecture?
You're mixing up things here. There is the 64 bit CPU architecture, then there is the 64 bit OS and last but not least there is the 64 bit application. While almost all x86 systems are nowadays really fully 64 bit CPUs, and most OSes are installed as 64 bit, the ratio of 64 bit applciations in comparison to 32 bit applications is still a lot smaller.
You can run 32 bit OSes on 64 bit hardware and you can run 32 bit applications on 64 bit OSes but never the opposite. LabVIEW is somewhat in a special situation as it is largely used in all kind of hardware related projects and most other hardware interface manufacturere still struggle to provide proper 64 bit support for current hardware and never will upgrade to 64 bit drivers for legacy hardware. So there is in fact a large user base who does not only not want to change to 64 bit LabVIEW but actually can't do so for quite some time in the future until they can replace their old hardware with new one, which NI would be very happy to sell them as almost all their hardware drivers are already fully 64 bit compatible. But that is for many systems not going to happen anytime soon.
So LabVIEW is still predominantly installed and used as 32 bit application, which works perfectly fine on all 64 bit system. Of course because of that there is less incentive to convert every possible toolkit to support fully 64 bit LabVIEW. Many of these toolkits were developed at some point and get maintainded but there is no real developer resource available to make substantial changes and given that most users still use 32 bit LabVIEW there isn't an immediate big need for that, which of course is a bit of a catch 22, since as long as not all toolkits support full 64 bit LabVIEW it is often not a good idea to try to switch.
But it's definitely not just NI itself but many other addons and third party libraries and many of them have a zero chance to ever get ported to 64 bit. That is just life and we can all lament and moan about it, or simply move on and get the work done with what we have.
Even if you are forced to use Windows 10 64-bit, LabVIEW 32 bit will run totally fine on it. And as there are some alternatives for most things, albeit not always for free, if you really want to go all 64 bit, I don't see where the big problem is.
@ijustlovemath wrote:
I understand the nuances of 32 vs 64 bit. And I do have many many 32 bit applications, but all of my development suites, VS being the main one, but also IntelliJ, eclipse, and to a lesser extent, autotools, all come in 64 bit. Not that we don't have 64 bit LabVIEW, but just that it doesn't make much sense why an application development platform with such a tightly controlled ecosystem doesn't offer the full range of deployment and development options that you might expect.
simply the hard fact of economic reality. Developers cost money, modifying an existing software library or product costs even more money as you have to completely test the software product again, build an installer, test it on a few zillion hardware combos and then also update all the documentation. That means for a simple thing as a LabVIEW toolkit many man weeks of work. Now let many of those toolkits all be bundled together as a free addon and you see that the bean counters have a simple calculation to do. Developer costs on one side against almost zero $ in extra sales and you know the outcome of that!
Another interesting fact is that one of the biggest hardware platforms of NI nowadays, their FPGA based cRIO and similar products is constrained by limitations of the used tools that are in fact partly beyond the control of NI. The whole FPGA toolchain they need for that is not yet ported fully to 64 bits. So they can't even release a 64 bit version of the FPGA development system at the moment. One more reason why 32 bit LabVIEW is going to stay for a few more years before they abandon that, which will surely cause a strong outcry from many who won't like that they are forced to go to 64 bit LabVIEW and forget about controlling their legacy hardware 
@rolfk wrote:
@ijustlovemath wrote:
I understand the nuances of 32 vs 64 bit. And I do have many many 32 bit applications, but all of my development suites, VS being the main one, but also IntelliJ, eclipse, and to a lesser extent, autotools, all come in 64 bit. Not that we don't have 64 bit LabVIEW, but just that it doesn't make much sense why an application development platform with such a tightly controlled ecosystem doesn't offer the full range of deployment and development options that you might expect.simply the hard fact of economic reality. Developers cost money, modifying an existing software library or product costs even more money as you have to completely test the software product again, build an installer, test it on a few zillion hardware combos and then also update all the documentation. That means for a simple thing as a LabVIEW toolkit many man weeks of work. Now let many of those toolkits all be bundled together as a free addon and you see that the bean counters have a simple calculation to do. Developer costs on one side against almost zero $ in extra sales and you know the outcome of that!
Especially when the vast majority of customers won't need/want it.
