Petition for NI to implement C99 standards into CVI

[dummy_decoy]

for the next C99 feature implemented: i'd like to see an implementation of snprintf() and all those missing functions from the standard library.

[Mert_A.]

Which other functions are you referring to? I'm aware of snprintf, vsnprintf, and a couple floating point environment functions.

Mert A.
National Instruments

[wally_666]

---

Unless your target is a real time controller I see no benefits in using LabWindows for developing Window apps.

---

Bingo!  I use Windows because its hardware is very cheap,  so I can create a good user interface to machines controlled by real time Linux.  I use a TCP/IP network to connect the non-real time user interface (real time enough for the user but not the machine) to the real time controller.  Its been a versitle setup for may years going back to CVI 3.  Windows means minimal training for the users.

The Linux runtime in some cases makes it possible to eliminte the user interface PC and network layer to run everything on the Linux box.  In other cases the post run analysis software is tied to a Windows envrionment so nothing is gained from eliminating the user interface PC which is generally a notebook used to run an experiment and then take the data home for later analysis.  Our operators have had no trouble moving from XP to Ubuntu Linux, usually less than when moving from XP to Vista -- another big strength of CVI is my old 5.5 code has needed no changes to work on Vista.

I'll take the worst C code I've ever seen over .net 's moving target any day!   The CVI 8 MSI installer has caused much grief with its inabality to let new and old versions of a project coexist.  My users tend to be conservative and want the previous version to fall back on if tpossible should hey discover an issue, and we often have minor variations of a project installed in different directories for slightly different experiments.  This is why I still use 5.5 for some things.

Ultimately its all throw away code as the hardware evolves the old software becomes useless as the hardware it was controlling no longer exists.  Minimizing development time is the highest priority behind correct and robust operation.  With CVI behind me I almost always have the first pass of software ready before the hardware changes are complete.  Other labs here using Visual C++ or LabView, usually sit and wait for the software ito be "finished".

--wally.

[Mert_A.]

The CVI distribution builder does provide a way to do the kind of side-by-side installs you're interested in. When you create a new distribution, you can point to an existing .cds file to copy all the settings from. This results in two distributions with separate identities, so they do not upgrade each other.

Mert A.
National Instruments

[menchar]

I do grow weary of cranking out lots of non-OO C code, but when it comes to being able to make an assertion to some hard nosed program manager who's squeezing pennies until Lincoln burps, CVI / C allows me to be reasonably certain I can meet requirements, generally on time.

Like it or not, C is still the lingua franca of technical / scientific SW, and C#, C++, and Java syntax is derived from C's.

And who really wants to be locked in hard to being led around by the nose in pursuit of Microsoft's profit motive?  We all live with their BS anyway, CVI allows us to minimize the pain to some extent. 

.net is essentially a SW monopolist's reaction to a great idea from Sun (java).  Microsoft spent untold millions putting 4,000 (!) microserfs to work trying to come up with an alternative to java.  And the .net stuff doesn't run on non-MS platforms!  This is the most incredible irony of all. Why go through all of the grief of a new SW architectural model and then not use it for what it was intended - write once run everywhere (WORE).  .net is a WORE architecture that doesn't run everywhere because MS makes their money being platform-centric.

If NI were to embrace an OO framework, Java is far more in line with NI's CVI philosophy of write once, run everywhere than the .net stuff.   NI had a scheme for deploying a platform-specific runtime onto multiple target types (the CVI RTE) long before sun came up with the java virtual machine.

I think it gets down to whether or not your target systems are exclusively Windows.  If they are, you're going to want to leverage the essentially-free tools from Microsoft and lean towards .net, probably writing in C# and maybe using Measurement Studio. (and that's exactly what we do for a lot of our stuff).  But even then, you've got to be really careful and not fall into the microsoft trap - easy and cheap to get 90% done, then you die trying to finish off the last 10%.

Gates is backing out almost completely from microsoft's operations - things are going to get volatile.  Vista may have been an "OS too far".

Menchar

[wally_666]

---

@Mert A. wrote:
The CVI distribution builder does provide a way to do the kind of side-by-side installs you're interested in. When you create a new distribution, you can point to an existing .cds file to copy all the settings from. This results in two distributions with separate identities, so they do not upgrade each other.

Mert A.
National Instruments

---

Thanks this is a nice work-around to know about for the several minor project variations in seperate directories issue, but virtually no help without a fair bit of burden on me with respect to keeping previous versions around for fallback or debugging.

Most of my users are astute enough to keep the previous installer around so they can go back to work and tell me about any  problems with the"update" by re-installing the old over the new.  While the new installer automatically updates the old to new,  it won't down grade the new without Add/RemoveProgrames->Uninstall first.  I get no end of complaints about this!

--wally.

[Mert_A.]

This approach to versioning is based in the idea that new software is backwards compatible, but old software is not forwards compatible. Of course that's not always be the case when bugs or other unexpected behavior changes are introduced in newer versions create problems in existing systems. It's still probably better than someone accidentally or naively installing some old software over the newer, removing functionality or re-introducing fixed bugs.

You're right that my proposed workaround involves multiple .cds files, though I'm not sure it adds much burden. If you intend to rebuild or debug older versions of your software, you must already be keeping frozen copies of the source around anyway. To build the old installer, you would still have to have the old source and the old .prj file. I'm just suggesting you also keep around a .cds file. I may be missing something; if so, let me know. We want to make sure we are providing good solutions to our users' use cases.

Mert A.
National Instruments

[wally_666]

That's the trouble with assumptions.  The old installer did everything I needed and nothing I didn't.  The new ones post 5.5 have just added a bunch of crap from my point of view and ballooned the size of the distributable for zero net benefit to me.  Now they are starting to actually annoy my users.

Pretty much anytime I change something that requires changes to the .cds file it triggers the "bitmap not valid" bug that has been discussed on this forum in the past, which make me exit CVI and try again.  PITA time waster, but since I usually don't mess with the .cds file after the first build or two its tolerable.

Thanks for listening.  Sorry this has gotten way of topic from C99 standards unless the new installer is a C99 compatability "feature" 

--wally.

[Mert_A.]

I would like to resolve the invalid bitmap issue, but have not gotten any logs back after posting the instrumented DLL. Since I posted it, the link to the DLL has gone stale, but if you would be willing to help, I've posted the zipped files directly to the thread. Read the original post, then refer to my latest post to actually get the files. I can't update the original (now broken) link.

Mert A.
National Instruments