Bug : LVRT ini file pollution/corruption... (leaves me speechless)

[rom1nux]

Hello,

I programming a platform independend autonomous datalogger in C based on 6009 and Nidaqmxbase but i see something strange in Windows platform about ini file

I see the lib hook al I/O access to overlappe file read/write and adding some keys especially in INI file with the exact same name of executable

For exemple you got [LVRT] at the top of the ini file, and this not be properly handle, this corrupt INI files lines

I lot my voice when i discover it ! leaves me speechless !

What did you do NI dev team ? did you think about performance & ressources & simplicity ? hum...

You can reproduce with the joined sample with MINGW and make.bat

Hop something respond me a day

rom1nux

[altenbach]

Since you posted in the LabVIEW forum, I assume your post has something to do with LabVIEW.

If it does, can you point it out for those of us who cannot see the connection. Thanks! 🙂

[rom1nux]

Hello,

Thanks for repond to me. I dont want to use LabVIEW, i'm C/C++ programmer, and when i use only  nidaqmxbase 3.5, but LabVIEW come to ennoye me.

I demonstrate there is a non-waiting interraction from LabVIEW in my code.

I dont want to see or use LabVIEW but lasy Ni Dev have decided otherwise....take a look in my reproductible sample...if you understand what i mean....what a perf lost and complicated non stable hooking procedures...

Can someone tell me how to dont have [LVRT] in my ini file with the exacte name og exe ?

rom1nux

[rom1nux]

Sorry for my bad english and i hop this is the good forum section....

I dont want to use LabVIEW, i dont know about LabVIEW, i juste want to write a C program with an .ini file (with the exact name of my executable) to simple store my program configuration...

Why my fprintf system call are hooked (ooverlapped?) by LabVIEW ? It corrupt my inifile and adding "[LVRT]" at bottom of my ini file....

I write a simple C file to demonstrate my discover....

I dont know how to publish this discover, it seem to be a LabVIEW program stack problem...so i choose this forum section....

I hop my explainations are clear...

Thanks in advance to find a workaround (without changing ini and exe filename)

Rom1nux

[Ben]

Is suggest you repost in your native tongue. Someone should be able to tranlate or respond directly.

It sounds like you suspect a LV fragment of code while using the NI drivers in a C environment but after that I am lost.

Ben

[rom1nux]

Hello Ben,

Thanks for you support.

i post here: https://decibel.ni.com/content/message/27165#27165

but there is not many people in this group....

"It sounds like you suspect a LV fragment of code while using the NI drivers in a C environment but after that I am lost."

Nearly : LABView interact with my C code and i dont want ! i'm only use "nidaqmxbase.h" in my code.

For exemple, in "acquirelvrt.exe" (joined reproductible .c source sample) when i write a single line into text file named "acquirelvrt.ini", someone (probably god ?) write the line "[LVRT]" in top of my "acquirelvrt.ini" file o_O !!!

I see this problem in a big application with a big ini file, the linux version work well, on Windows the ini file is corrupted !

- if i only change the name of ini, it work !

- if i only change the name of executable, it work !

- if i comment all NI codes and dont link "nidaqmxbase.h", it work !

I search for hours before googleling [LVRT] and see it's a NI product...so  i suspect LabVIEW...

hop you understand why i'm here...

Is suggest you repost in your native tongue

Ok... good idea, sorry for my bad english, thanks for effort to understand me.

Another thanks for repond to me and dont leave me alone, i m going to write in my forum language section

best regards

[Ben]

The type of change you are requesting to avoid the issue you are seeing would take years to implement (it takes about 5 miles to rurn an aircraft carier around) and would affect every app out there that relies on the ini file naming as it stand now.

So the best i can do is suggest you treat the name as "reserved" to NI and work around it.

Ben

[rom1nux]

Hello Ben,

The type of change you are requesting to avoid the issue you are seeing would take years to implement

Hum...you get right, but in "C world" this kind of things is a complet "non-sens"...

if we use C, this is because we want to know exactlly what we do !

Getting accross a lib wich can produce this kinds of non-documented manipulations is not very safe in my world...

immediatly we get doubt  "...what other surprising things this library can reserved...", "...does it coded with feet..."

And more scarry, why this strange not-documented backgrounded operations dont work properlly ? (ie: corrupt acces to file with simple fprintf() )

Look what kind of code NI devs need to "hook the I/O systems-calls" and your begin to think about performance and ressources losts, and begin to be really scarry...

Other thing, basic, why something "normally disabled" (ie: LABView) want to write to a config file ? and what he use my own system call ?

Hum..yes...this takes years to re-implement 😉

So the best i can do is suggest you treat the name as "reserved" to NI and work around it.

Yes, this is what we do, but for our case this is quiet the "straw that broke the camel", too much problem/limitation/workaround on linux version...seem identical on Windows...

I have to check if Nidaqmxbase3.4.5 got improvements...My boss goes to decide in few day...he currently look if mcc is according real C philosophies...

Thanks a lot for your Help and your suggestions

Rom1nux

[Ben]

---

@rom1nux wrote:

Hello Ben,

The type of change you are requesting to avoid the issue you are seeing would take years to implement

Hum...you get right, but in "C world" this kind of things is a complet "non-sens"...

if we use C, this is because we want to know exactlly what we do !

Getting accross a lib wich can produce this kinds of non-documented manipulations is not very safe in my world...

immediatly we get doubt  "...what other surprising things this library can reserved...", "...does it coded with feet..."

And more scarry, why this strange not-documented backgrounded operations dont work properlly ? (ie: corrupt acces to file with simple fprintf() )

Look what kind of code NI devs need to "hook the I/O systems-calls" and your begin to think about performance and ressources losts, and begin to be really scarry...

Other thing, basic, why something "normally disabled" (ie: LABView) want to write to a config file ? and what he use my own system call ?

Hum..yes...this takes years to re-implement 😉

So the best i can do is suggest you treat the name as "reserved" to NI and work around it.

Yes, this is what we do, but for our case this is quiet the "straw that broke the camel", too much problem/limitation/workaround on linux version...seem identical on Windows...

I have to check if Nidaqmxbase3.4.5 got improvements...My boss goes to decide in few day...he currently look if mcc is according real C philosophies...

Thanks a lot for your Help and your suggestions

Rom1nux

---

With great power comes great complexity. I'm still learning everything that has bee dumped on my brain.

Pssst don't tell anyone but....

mcc is now owned by NI.

Ben

[rom1nux]

Ben,

With great power comes great complexity

Yes, but NI is at point where simply acquire a channels involve this kinds of side effects...(look my reproductible code, is so simple...)

This is not why i named "great power"

Pssst don't tell anyone but....mcc is now owned by NI.

I know nothing about mcc, hop this not the same dev teams...and drivers architecture.

We just receive a sample to discover...we do ours own experiment...

I you know some "Well C oriented" DAQ, let me know

It's quiet difficult to explain my problem, i send photo where you can see here what kind of autonomous application box i try to do !

All of this be writing in C, no GUI, based on small i386 "Vortex86(1Go/256Mo)" and NI6009 working on Linux and Windows

I hop you understand why i'm very surprising why LabVIEW sudently come in place in my kind of project...

I why i'm scarry about ressources consumption

Best regards

Rom1nux