Executable Directory Structure

When building an executable in Labview some VIs may be remapped to a different folder structure either inside or outside the executable. This can impact an executable that uses path constants in source code to locate sub VIs or other resources. Versions prior to 2009 remapped VIs to a directory tree outside the executable. Labview 2009 has fixed this problem.

Yes, by default all VIs will go into the .exe using the same relative path between them as you had outside the .exe (you can, of course, tell the build spec to put specific VIs in specific locations using custom destinations). It finds the most common root folder of all the VIs and uses that as the top-level directory inside the .exe. If the VIs span drives on Windows then the top-level directories will be the drive letters.

The one exception is vi.ilb, which gets its own top-level directory. This is to prevent common cases from having really deep hierarchies just for vi.lib VIs. This means if you call a vi.lib VI dynamically then you should write a wrapper VI for it in your .exe which you can then call using a relative path. The idea is to not have any code which has to check whether you're in an .exe or not in order to build different paths. The paths should always be the same.
(Quoted from Adam Kemp on LAVA)

For example, an executable's internal directory structure would look like:

application.exe/main.vi
application.exe/subfolder/subvi1.vi
application.exe/LabVIEW 2009/vi.lib/vilibVI1.vi
application.exe/LabVIEW 2009/user.lib/_OpenG/openGVI.vi
application.exe/LabVIEW 2009/instr.lib/Instrument Driver1/initialize.vi
(Quoted from gmart on LAVA)