LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Petition for NI to implement C99 standards into CVI

Hello Wayne,
 
First, let me say how much I appreciate the fact that you've been using CVI for so long. You raise some valid points about our history, and I'm not going to try to justify some of those past statements, which frankly seem quite asinine to me.
 
As far as CVI and Unix is concerned, as you know, NI did support Solaris up until version 5.0 of CVI, and the reason we stopped supporting it, frankly, was because the sales became negligible at that point. To the extent that we could no longer justify the engineering cost of maintaining both versions. Shortly thereafter, we started receiving some requests for a Linux version. We tried to gauge the amount of interest as best we could, and when it became large enough, we decided to invest the effort of creating a CVI runtime module for Linux -- basically, not the full ADE, but something that would allow you to build and run your applications in Linux. This addressed the majority of our requests at the time, and the idea was that we would monitor feedback from that point on, and see how much interest there would be for NI to support the full-blown ADE in Linux. That's where we stand today. So to summarize, I want to reassure you that we do monitor user feedback and do respond to it, but it's also true that the interest needs to rise to a certain level before we can justify shifting resources from one feature to another.
 
Hopefully, that makes sense Smiley Happy
 
Thanks again for the feedback!
 
Luis
NI
0 Kudos
Message 10 of 29
(5,355 Views)
Thanks Luis for the response.

I do understand very well the business reasons for choosing the direction a
company makes to stay solvent. However, there are many companies that make
a living despite the fact that they choose to be cross platform.  A case in
point is one of your very own products, LabVIEW.  It is supported across
more than one platform.  I am assuming that this was a decision based on
interest shown, but I am willing to bet that the design of the software
makes it more business sensible.

I think that the choice to support a product across platforms has more to
do with the design of the software than whether it makes business sense.
The design choices made in the beginning, will influence the business
decisions made in the end.  A product designed heavily on a specific
platform is more costly to support across platforms.  I understand that all
too well.

Asinine? Maybe, but then that is relative to what side of the reasoning you
stand on.

Wayne



0 Kudos
Message 12 of 29
(4,343 Views)
Some Linux runtime feedback:

So far I'm thrilled with the results, less than thrilled with the general documentation, installation instructions, and fact that its already two releases behind the WIndows current release.

While a full IDE on Linux would be nice,  CVI 8 seems to run fine in a Windows virtual machine (using VirtualBox on Ubuntu 6.06) so I can develop on Linux.

Using  #ifdef __WIN32__ #else #endif to handle the differences (mostly file access stuff for us) between the Windows and Linux versions works well enough for now.  The name collision in the CVIBUILD.projectname between the Linux and windows versions is an irratition when trying to maintian the Windows and Linux versions in the same shared directory

ANSI/C99 compliance is of no practical significance for me.  C++ is way more trouble than its worth for what I do.

--wally.

0 Kudos
Message 13 of 29
(4,329 Views)

Hi Wayne,

What you're saying makes sense, of course. As a point of trivia, I'd only add that both LabVIEW and LabWindows/CVI (and by that I mean, the 3.0 and later versions, not the DOS version) were designed to be cross-platform, otherwise it would probably not have been feasible to have had the Solaris version between versions 3.0 and 5.0. However, I want to point out that even with an application designed to be cross-platform there are very significant engineering costs involved in maintaining the product in multiple platforms. For LabVIEW, the business decision was made that those costs are justified, whereas that wasn't the case for CVI. That is to date, of course. Just like this changed for the 8.0 version of the Linux runtime module (the limitations of which Wally has already addressed) it can still change again in the future.

Luis

0 Kudos
Message 14 of 29
(4,311 Views)
C99 enthusiasts,

As you may have already noticed, there is now a poll up on the forum message listing to gather input about the most wanted C99 features.  Just as we did with CVI 8.5, we may add some C99 extensions in future releases, so we would like to get your input about what is most important to you.  If you don't care about C99 features, or only really want one or two specific extensions, you can use the "None of the above / Not interested" option to indicate that.

Mert A.
National Instruments
0 Kudos
Message 15 of 29
(4,229 Views)
Variable length arrays are most popular C99 enhancement request.

I guess I'm curious why. 

Is it that you can be certain of dynamically allocating a large enough array in every case?  Saves you the malloc / free hassle for run-time determined array size? 

Does variable array work with static storage class?  If not, they'll always be on the stack, unlike malloc'ing an array.

I guess the kicker to all of this is if we start using it as an incomplete C99 implementation, we're not really compatable in a couple of ways:

1.  Not backwards compatable, obviously.
2.  Not cross compatable in both directions with a true C99 implementation.

How many fully compliant C99 compilers are out there?  Looks to me from google search that most all of the fully C99 compliant compilers are for Linux (!)

On the Winders side, Comeau and LCC are the only ones I can find (!) 

Menchar


0 Kudos
Message 16 of 29
(4,147 Views)

Why not port the whole lot to to .net and save a lot of development time and mony.

That's the way we program in windows these days and that the direction Microsoft is going.

This would solve a lot of problems as it would be Microsoft who do most of the work.

Keep the c version for those that like cryptic and unmanaged code.

I hate panels and the old fashioned way off doing things so I use measurement studio instead.

Colin

 

 

0 Kudos
Message 17 of 29
(4,078 Views)


Colin hughes wrote:

Keep the c version for those that like cryptic and unmanaged code.



You're kidding, right??  😮
0 Kudos
Message 18 of 29
(3,210 Views)
As far as next implemented C99 features -

I'll assume that NI fixes up intra-block declarations using typedefs in some upcoming release.

I'm thinkin' I'd like to see non-constant initializers for variable declarations.  Or some way to get a double initialized to NaN with a constant.

Menchar


Message Edited by menchar on 06-23-2008 11:51 AM
0 Kudos
Message 19 of 29
(3,151 Views)
Unless your target is a real time controller I see no benefits in using LabWindows for developing Window apps.
Measurements Studio is bar better if you understand oops.
Who else wrights Window programs in 'c'. these days?
'cpp' perhaps then I might be interested. 
 
Colin
 
0 Kudos
Message 20 of 29
(3,092 Views)