LabVIEW Developers Feature Brainstorming

[Noel]

Note (August 2008):  Thanks to all of the users who have provided feedback on these proposals.  At this time, NI is likely to proceed with the proposed LabVIEW API to access system directories.  However, NI has suspended plans to implement the proposed changes to the LabVIEW directory structure.  The proposed LabVIEW directory changes originated internally based on anticipated demand for NI to adhere to Microsoft Vista's directory recommendations. Since imposing a new directory structure impacts Alliance members and many of our other customers, we have decided to suspend these changes until there is a greater customer demand.

Hello:

With the introduction of Microsoft’s Windows Vista, it is increasingly important that LabVIEW and end-user applications follow the OS directory usage guidelines. Since all major operating systems highly encourage a dispersed directory structure, we plan to change the LabVIEW directory structure across all platforms in a future release of LabVIEW. These changes will occur in a 2009 or later release and will not appear in the LabVIEW version currently in Beta (as of March 2008).

Since we expect end-users to strongly consider changes to their own application directory structure, we know communication is vital to facilitate a successful transition and minimize impact to end-user applications. This is the first of several forum posts related to
1. Proposed LV API to access system directories
2. Proposed changes to the LabVIEW directory structure. 

We split these apart so customers who build their own apps can focus on system directory access (1) and customers who place files into the LabVIEW directory can focus on changes to the LabVIEW directory structure (2).

We’ll try to preemptively channel topics by “seeding” questions through different posts.  We’ll also have a “catch all” post to cover any additional questions/concerns/suggestions. 

We look forward to your feedback. We are confident that strong communication will help us minimize customer impact and facilitate a successful transition.  Refer to separate forum posts for various followup questions.

Regards,
Noel Adorno
LabVIEW R&D

Message Edited by Support on 08-21-2008 01:43 PM

[Jim_Kring]

Noel,

Thank you for taking time to solicit feedback from users on these important issues.  I have posted messages on OpenG and LAVA with link to these topics.  I'll be posting my thoughts and questions, for sure

Thanks,

-Jim

[Peter_B]

Hi there,

My post involves system DIRs as defined in the LabVIEW environment.  I am having problems because LabVIEW changes one of its system DIRs on me causing a previously called shared library (DLL) to crash (BSOD)

I think the name of the system DIR is the local User Home DIR.  Let me define this as the User_Home_DIR for want of a better name.  More specifically at any point in time the DIR I refer to is the DIR defaulted to when one launches a DOS box by running the System Exec.vi and pass it the command "cmd". 

So here is the sequence of events:

1.  I launch a 3rd party dll by specifying the full path to that dll (<My_DIR>\3rdParty.dll) from the BD.  . This will set User_Home_DIR = My_DIR. If the User_Home_DIR then changes , subsequent calls to that DLL cause it to crash as it expects a whole bunch of files to be at My_DIR.

2. Here is how the User_Home_DIR changes. Somebody clicks a Browse Button on an unrelated Path control on the FP to select an unrelated file e.g. <another_DIR>\<another_file.txt>  That file resides in <another_DIR> which is unrelated to My_DIR, however LabVIEW proceeds to set the User_Home_DIR = <another_DIR>. Why LabVIEW does this I don't know but it is causing me grief because:

3. A Subsequent call to 3rdParty.dll (which was never unloaded from memory) then causes it to rely on the new path and it can't find its original files 'cause they aren't in the new path.

Here is my question:

How can I programatically set the User_Home_DIR back to My_DIR before I make subsequent calls to 3rdParty.dll ?

thanks in advance

regards

Peter Badcock

ResMed Ltd

Message Edited by Peter_B on 01-29-2009 09:16 PM

[PhillipBrooks]

Sorry, but these are not supported.

Read the first few paragraphs in the link you provided, or see this related post.

This document is the first proposal for the changes regarding access to system directories that will occur in a future version of LabVIEW. Our goal is to work with the LabVIEW community to provide guidelines on proper usage of system directories. This will provide a general overview of the changes. In the future, we plan to provide many more details.

This proposal originates from a LabVIEW Feature Brainstorming discussion post titled System directory access and LabVIEW directory changes.

These changes will not occur in LabVIEW until 2009 or later.

For information on using the currently supported 'symbolic paths', see the LAVA wiki : http://wiki.lavag.org/Symbolic_Path

Message Edited by Phillip Brooks on 01-30-2009 06:37 AM

[rolfk]

---

Peter_B wrote:

Hi there,

My post involves system DIRs as defined in the LabVIEW environment.  I am having problems because LabVIEW changes one of its system DIRs on me causing a previously called shared library (DLL) to crash (BSOD)

I think the name of the system DIR is the local User Home DIR.  Let me define this as the User_Home_DIR for want of a better name.  More specifically at any point in time the DIR I refer to is the DIR defaulted to when one launches a DOS box by running the System Exec.vi and pass it the command "cmd". 

So here is the sequence of events:

1.  I launch a 3rd party dll by specifying the full path to that dll (<My_DIR>\3rdParty.dll) from the BD.  . This will set User_Home_DIR = My_DIR. If the User_Home_DIR then changes , subsequent calls to that DLL cause it to crash as it expects a whole bunch of files to be at My_DIR.

2. Here is how the User_Home_DIR changes. Somebody clicks a Browse Button on an unrelated Path control on the FP to select an unrelated file e.g. <another_DIR>\<another_file.txt>  That file resides in <another_DIR> which is unrelated to My_DIR, however LabVIEW proceeds to set the User_Home_DIR = <another_DIR>. Why LabVIEW does this I don't know but it is causing me grief because:

3. A Subsequent call to 3rdParty.dll (which was never unloaded from memory) then causes it to rely on the new path and it can't find its original files 'cause they aren't in the new path.

Here is my question:

How can I programatically set the User_Home_DIR back to My_DIR before I make subsequent calls to 3rdParty.dll ?

thanks in advance

regards

Peter Badcock

ResMed Ltd

Message Edited by Peter_B on 01-29-2009 09:16 PM

---

You are not talking about the user home dir here most likely but about the current directory. This is a variable maintained by the OS on a per application base and can be changed with the Windows API function SetCurrentDirectory() and read with GetCurrentDirectory(). There is also a C runtime function chdir() on any Posix compliant system (yes Windows 32 bit is mostly Posix compliant too).

LabVIEW does absolutely nothing with the current directory in any way, either changing it or using it directly. However many Windwos API functions do so. LoadLibrary() used to load a DLL, does for instance at one moment after having tried anything else also trying to load the DLL when specified without full path from the current directory too. But some Windows API functions change that variable also. So does the file dialog set the current directory to the currently selected directory whenever it is dismissed with the OK or according positive acknowledgement button.

So the problem is not LabVIEW in any way but simply that the current directory is a very bad directory to let Windows look for shared libraries (DLLs).

If you need to have Windows find your shared libraries reliably you need to read this post and put those libraries in the according locations. For evelopment the best location is often to put them in some directory and modify your PATH environment variable to contain that directory and for distributed apps I always make sure to include the DLLs in the application directory itself unless they are positively system DLLs (from the Windows or System32 directory) or come with their own installer because they also go together with kernel device drivers, system services or other kernel related stuff that needs to be registered in the system correctly by an installer that knows about all the intimate details to make that driver/shared library work on a system.

Rolf Kalbermatter

[Peter_B]

Hi Rolf,

Thanks for your explanation. I have attached a vi which proves to me that LabVIEW does change its current working DIR. This is what was causing all my grief. I now have a workaround by changing it back using SetCurrentDirectoryA() - also attached.

When you wrote "LabVIEW does absolutely nothing with the current directory in any way," did you mention an exception to that when you also wrote "the file dialog set the current directory to the currently selected directory whenever it is dismissed with the OK or according positive acknowledgement button." ?   Perhaps you are referring to what is happening in my attached vi "System DIR changing v0.2.vi"

I agree with you entirely "that the current directory is a very bad directory to let Windows look for shared libraries (DLLs)."  It is a 3rdParty.dll and I don't have the ability to modify it right now.

regards

Peter Badcock

ResMed Ltd

Message Edited by Peter_B on 02-01-2009 02:59 PM

[rolfk]

---

Peter_B wrote:

Hi Rolf,

Thanks for your explanation. I have attached a vi which proves to me that LabVIEW does change its current working DIR. This is what was causing all my grief. I now have a workaround by changing it back using SetCurrentDirectoryA() - also attached.

When you wrote "LabVIEW does absolutely nothing with the current directory in any way," did you mention an exception to that when you also wrote "the file dialog set the current directory to the currently selected directory whenever it is dismissed with the OK or according positive acknowledgement button." ?   Perhaps you are referring to what is happening in my attached vi "System DIR changing v0.2.vi"

I agree with you entirely "that the current directory is a very bad directory to let Windows look for shared libraries (DLLs)."  It is a 3rdParty.dll and I don't have the ability to modify it right now.

---

Well, LabVIEW does nothing. It is the Windows System File Dialog that does this. I'm not sure but I do believe that MS added a new flag in the latest versions of Windows to the system dialog API to tell it to not change the current directory but that wouldn't work for older OS versions anyhow and in fact cause possibly other problems because of the resulting inconsistencies of LabVIEW applications when run on different OS versions.

And later posts I saw from you made me wonder if it is really a DLL your DLL is searching or not just some other files. For DLLs making sure they reside in the locations Windows will search would be the solution. For other files this won't work. Some Win API file IO functions will automatically locate files specified by relative path by using the current directory as starting point. A DLL relying on such behaviour is indeed flawed badly and should not make it into a released product.

Rolf Kalbermatter

[Peter_B]

---

rolfk wrote: 

Well, LabVIEW does nothing. It is the Windows System File Dialog that does this. I'm not sure but I do believe that MS added a new flag in the latest versions of Windows to the system dialog API to tell it to not change the current directory but that wouldn't work for older OS versions anyhow and in fact cause possibly other problems because of the resulting inconsistencies of LabVIEW applications when run on different OS versions.

And later posts I saw from you made me wonder if it is really a DLL your DLL is searching or not just some other files. For DLLs making sure they reside in the locations Windows will search would be the solution. For other files this won't work. Some Win API file IO functions will automatically locate files specified by relative path by using the current directory as starting point. A DLL relying on such behaviour is indeed flawed badly and should not make it into a released product.

Rolf Kalbermatter

---

Thanks again Rolf.  Yes the 3rdParty.dll expects certain text/log files (not dlls) to be in a spot relative to that default working DIR.   I agree the 3rdParty.dll has a bad dependency that should be fixed up. Until then I'm working around the problem as described previously.

I'm probably splitting hairs here but I think that NI or LabVIEW should have warned me about this "behind the scenes" behaviour that is guaranteed to happen every time somebody presses the LabVIEW browse button icon and selects a file in all but the current working DIR.  I wonder if the LV development team were even aware of the behaviour ?  Anyway such discussions are now academic in nature.

For the sake of completeness (and not to generate further discussion) I'm including a link to the cross post I last made on this topic Info LabVIEW here.

regards

[rolfk]

---

Peter_B wrote:

Thanks again Rolf.  Yes the 3rdParty.dll expects certain text/log files (not dlls) to be in a spot relative to that default working DIR.   I agree the 3rdParty.dll has a bad dependency that should be fixed up. Until then I'm working around the problem as described previously.

I'm probably splitting hairs here but I think that NI or LabVIEW should have warned me about this "behind the scenes" behaviour that is guaranteed to happen every time somebody presses the LabVIEW browse button icon and selects a file in all but the current working DIR.  I wonder if the LV development team were even aware of the behaviour ?  Anyway such discussions are now academic in nature.

For the sake of completeness (and not to generate further discussion) I'm including a link to the cross post I last made on this topic Info LabVIEW here.

regards

---

Lol, splitting hairs you are indeed!

The current directory is an artefact from single threading OS times such as DOS and Windows 3.1 and has absolutely no useful meaning in a multithreading environment. Any driver DLL your LabVIEW program might call, could affect that current directory directly through use of the SetCurrentDirectory() API or implicitedly by calling some Windows API or other DLL that affects this variable. Also which Windows APIs affect this variable is at best described as a side note in the MSDN documentation if at all and can change with Widnows versions too.

So relying on current directory in a modern Windows, Linux or MacOS application (not sure MacOS has that but I assume at least its Unix kernel would) is simply bad UNLESS you control the entire environment the application consists of including any DLLs. So for command line tools this can be feasable (not sure how inheritence of child process would affect the current directory though) but anything else and especially DLLs meant to be called from various environments simply can't rely on that. Basta!

The LabVIEW developers are certainly aware of the specific change of the current directory in the system dialog but working in the various multithreading environments for so long they likely never had the idea that some braindead DLL developer would rely on the current directory to be some magic value and to remain so. He obviously never tested that DLL in a real world scenario which would make me hesitate even more to use it in a production type application unless I had the source code to it.

Rolf Kalbermatter

Message Edited by rolfk on 02-03-2009 10:11 AM

[Jim_Kring]

---

Noel wrote:

Note (August 2008):  Thanks to all of the users who have provided feedback on these proposals.  At this time, NI is likely to proceed with the proposed LabVIEW API to access system directories.  However, NI has suspended plans to implement the proposed changes to the LabVIEW directory structure.  The proposed LabVIEW directory changes originated internally based on anticipated demand for NI to adhere to Microsoft Vista's directory recommendations. Since imposing a new directory structure impacts Alliance members and many of our other customers, we have decided to suspend these changes until there is a greater customer demand.

---

Hi Noel,

Have there been any changes to the status since last August?  Any plans to move forward with the LabVIEW directory changes anytime soon?

Also, when updating (editing) a post, please also post a Reply to the thread so that subscribers get notified of the change -- nobody recieves notification when a post is simply edited.

Thanks,

-Jim