Final LabVIEW Release: 2023Q3

[infinitenothing]

I was about to build an executable for a OS X customer when I noticed that it won't be possible for much longer:

https://www.ni.com/en/support/documentation/compatibility/18/labview-and-macos-compatibility.html

This surprised me because I know the founders were hard core mac enthusiasts and also because usually large companies will put something like this on their road maps so that people can plan better.

[Antoine Chalons]

Out of curiosity, can you describe a bit your customer project that runs on OS X?

Edited May 14 by Antoine Chalons

[infinitenothing]

There's a PXI based hardware system that generates TDMS data logs and the project is a viewer/analysis tool for those data logs.

Edited May 14 by infinitenothing

[Antoine Chalons]

Ok, would it take a lot of work to port it to Linux desktop or Windows?

[infinitenothing]

Most customers use Windows and that is the primary target. We want to support all our customers though. 

[ShaunR]

This wouldn't be much of an issue since you could always use an older version of LabVIEW to compile for that customer. However. Now LabVIEW is subscription based so hopefully you have kept copies of your old LabVIEW installation downloads.

[infinitenothing]

The problem is that some day the customer will buy a new Apple laptop and that new laptop will not support LV2023. We need maintenance releases of LabVIEW RTE to keep it all working.

Edited May 15 by infinitenothing

[Rolf Kalbermatter]

On 5/15/2024 at 9:57 AM, ShaunR said:

This wouldn't be much of an issue since you could always use an older version of LabVIEW to compile for that customer. However. Now LabVIEW is subscription based so hopefully you have kept copies of your old LabVIEW installation downloads.

It seems they are going to make normal ordering of perpetual licenses possible again. While the official stance was that the perpetual licenses were gone, the reality was that you could still order them but you had to be VERY insisting, and have some luck to know the right local NI sales person, to be able to order them. That will of course not help with a current Macintosh version of LabVIEW. Still, maybe some powers to be might decide that reviving that is also an option. Kind of doubt it as I have experience with trying to support Mac versions of LabVIEW toolkits that contain external compiled components and the experience is nothing short of "dramatic". But if there would be a client teasing NI convincingly about ordering a few thousand seats of LabVIEW if there was a Mac version available, I'm sure they would think very hard about that. 😁

Edited May 22 by Rolf Kalbermatter

[ShaunR]

On 5/15/2024 at 5:13 PM, infinitenothing said:

The problem is that some day the customer will buy a new Apple laptop and that new laptop will not support LV2023. We need maintenance releases of LabVIEW RTE to keep it all working.

It doesn't have to. Just back-save () to a version that supports the OS then compile under that version. If you are thinking about forward compatibility then all languages gave up looking for that unicorn many years ago.

54 minutes ago, Rolf Kalbermatter said:

It seems they are going to make normal ordering of perpetual licenses possible again.

That is excellent news.

[Rolf Kalbermatter]

3 minutes ago, ShaunR said:

It doesn't have to. Just back-save () to a version that supports the OS then compile under that version. If you are thinking about forward compatibility then all languages gave up looking for that unicorn many years ago.

Unfortunately, Apple manages to almost consistently break backwards compatibility with earlier versions for anything but the most basic "Hello World" application. And yes that is only a mild exaggeration of the current state of affairs. For an application like LabVIEW there is almost no hope to be compatible over multiple OS versions without some tweaks. Partly this is caused by legacy code in LabVIEW that uses OS functions in a way that Apple has declared depreciated versions ago, partly it is simply because that is considered quite normal among Apple application developers. For someone used to program to the Windows API, this situation is nothing short of mind boggling.

 

[ShaunR]

13 minutes ago, Rolf Kalbermatter said:

For someone used to program to the Windows API, this situation is nothing short of mind boggling.

Not so much mind boggling - I used to support VxWorks .  It's not just Apple OS's though. Linux is similar. The same mind-set pervades both ecosystems. I used to support Mac, Linux and Windows for my binary based products because LabVIEW made it look easy. Mac was the first to go (nobody used it anyway) then Linux went (they are still in denial about distribution).

[Rolf Kalbermatter]

1 hour ago, ShaunR said:

Not so much mind boggling - I used to support VxWorks .  It's not just Apple OS's though. Linux is similar. The same mind-set pervades both ecosystems. I used to support Mac, Linux and Windows for my binary based products because LabVIEW made it look easy. Mac was the first to go (nobody used it anyway) then Linux went (they are still in denial about distribution).

VxWorks is quite special. It looks on many fronts like a Posix platform, but that is only a thin and not complete layer above the lower level and very specialized APIs. Programming to that lower level interface is sometimes required for specific operations but documentation was only available as part of the very expensive developer platform with according compiler. It's of academic interest now since VxWorks has been deprioritized by WindRiver in favor of their own Linux based RT platform. And NI has long ago stopped using it and never made the move to anything beyond 6.3 of the OS. It was anyhow only intended for the PowerPC hardware since they moved to that platform as power efficient embedded targets were not really an option on x86 based hardware at that time. But with the PowerPC loosing pretty much all markets, it was a dead end (at some point in time it was the most used embedded CPU solution, many printers and other devices, where users never ever saw anything of the internal hardware, were running on PowerPC).

It was hard to port any reasonably sized code to VxWorks because of the higher level APIs often being very similar to other Posix platforms like Linux, but not always working exactly that way or not providing certain functionality on that level. Accessing the lower level API was very difficult because of the very limited documentation about it that could be found without investing an arm and a leg into the developer platform from WindRiver. But once that porting was done there was fairly little maintenance required both because the API stayed fairly consistent and NI didn't move to a different version (except VxWorks 6.1 to 6.3 between LabVIEW 8.2 and 8.5).

Edited May 22 by Rolf Kalbermatter