From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

64 Bit Labview

Solved!
Go to solution

@BosonResearch wrote:

I naively thought the 64 bit version would perform fine on my 64 bit Windows 7 machine. My VIs had been fine under 32 bit LabView 2012, but I needed to change computers, hence updated. After doing a repair and a reinstall trying to determine why my Active X control stopped being operable (both suggested by NI support) a different support person informed me that they don't recommend the 64 bit version, it has a number of unsupported features. I wish they made that a little more obvious, even stating it on the downloads page, I'm frustrated at the large time waste this caused. Putting out a product that's not quite ready to work across the spectrum without being frank with the users is a stupid move, not one I expected from NI.


What ActiveX component did you have problems with? While the Active X interface in Windows is in principle able to bridge the 32 bit to 64 bit barrier with its internal mashalling that also allows to use ActiveX components in out of process situations, this is something that many Active X components will have trouble to fully support especially if you talk about Active X controls that have an UI to be hosted by the caller.

 

The problem with these things is that, while NI has in several places stated about the possible difficulties with 64 bit applications, and themselves haven't ported everything they make and use to 64 bit, they do support 64 bit for many of their products including their hardware components (even older ones), which still can't be said from many others. And if it is a 3rd party software they have of course no way of guaranteeing that it would work.

 

Your problem is that you jumped the gun on something without first doing a test and then got upset that it didn't work. In software development you really never should change anything in the used software versions and releases without first making a test that the changed software still works and of course keeping a full version history including backups (source code control) of any earlier versions.

 

Blaming NI for not documenting every possible problem that such an upgrade might cause, is a little bit short sighted. First there is quite a bit of documentation about this and while the document you quote has a modification date that is after your initial post, there have been other documents that talked about various possible gotchas and a myriad of posts in these forums too. And if they did write such a document as you think about, they would have to put many of the current LabVIEW developers into the documentation departement and let them write documents with thousends of pages that nobody ever would read before running into exactly those problems as you have found out. And that resource leak into software developers obviously would make it a lot harder to develop new features in LabVIEW, that we all like to see regularly.

Rolf Kalbermatter
My Blog
0 Kudos
Message 11 of 11
(612 Views)