DLLs - Export of VI mandatory

I'm reading the Help entitled "Building a Shared Library (DLL)", and step 5 says, "...select the VI you want to define as an exported VI in a shared library. You must define at least one VI to export as a function in the shared library".
What does this mean. I'm not sure what I'm really 'exporting' and why.

I'm trying to determine the best way to setup my LabVIEW project. I have all my HMI code, which I currently have laid out in a labview project. Now I'm bringing in some UUT-specific software (we'll ultimately have 14 UUTs, but we're currently at five). If I want to encapsulate the individual UUT code into their respective DLLs, can't I still have the same project file, but now I'd have 5+ Build Specifications. The only reason I'm considering the project option is that LabVIEW 8.5 finally allows me to synchronize my actual directory structure with that of the project. What I'm not sure, however, is if there is a 'refresh' of sorts to see when something has been added.

Similar Messages

NFS exports and the mandatory no_root_squash

We are running a SUSE11/OES11 cluster serving NSS volumes as NCP, NFS and AFP. Is the only feasible workaround for the NFS no_root_squash requirement to firewall the mountd port?
If so will having a list of 1,000+ IP numbers in the allow list for mountd have a significant impact on the cluster nodes? Unfortunately on our University class B IPv4 site the allocated IP addresses are scattered and the subset of PCs controlled by technicians (and therefore 'trusted') are not contiguous and neatly arranged.

There is another workaround to the "no_root_squash" requirement. The below is taken from TID: Support | OES: Compatibility issues between NSS and NFS
2. no_root_squash: Officially, this is mandatory, so care should be taken to limit what hosts can mount the export (as the root user of the NFS client host will be able to act as the root user on the NSS exported path).
However, due to potential security concerns with allowing root access, some administrators chose to set this up in another way. This alternative way is thus far considered experimental, and not thoroughly tested: It seems that the key requirement here is that the user who is requesting the mount (typically root) have at least Filescan rights to the NSS volume. If root is "squashed" he is treated like "nobody." Typically, "nobody" does not have access, neither through its own merits nor by being associated with any LUM-enabled user in eDir. However, an eDir user can be created and LUM-enabled, given Filescan right to the NSS volume(s), and then the UID assigned to that user can be used as the "anonuid" for that particular export. So, for example, if the user in question was given UID 1011, then instead of "no_root_squash" the combination of "root_squash,anonuid=1011" could be used.
In that case, be sure to remember that even after mount, "squashed root user" will be treated as having whatever rights the anonuid user has been given. Also remember that if you use the "all_squash" parameter as well, all NFS client users (not just eDir users and not just root) will be treated as the anonuid user, and will be able to access the NSS volume.
On the other subject: I do not know the potential impact of 1000+ IP numbers in an allow list for mountd.
Darcy

Exporting symbols in a .exe for external DLLs

Hello,
I am facing a strange problem.
Basically, I have my application that loads a DLL (I developped).
My DLL exports functions I can call from my application : OK
I would also like to call functions of my application from my DLL : it does not work.
To do that, in my DLL, I call :
HMODULE hModule = GetModuleHandle("application.exe");
FARPROC hFunc = GetProcAddress(hModule, "appFunction"); // (defined by : void __declspec(dllexport) appFunction(void) in my application
hModule is non-zero but hFunc is NULL. When I use a tool to see exported symbols by application.exe, there is none.
So my question is : Can I export symbols from a .exe with LabWindows 8.5 ?
thanks in advance
Solved!
Go to Solution.

Thank you for your answer,
I had already tried with :
HMODULE hModule = LoadLibrary("application.exe");
and
HMODULE hModule = LoadLibraryEx("application.exe", NULL, 0);
it gives the same result.
To be more precise here is the source code of dll.dll :
#include <Windows.h>
#include <stdio.h>
typedef void(*APPLI_PRINTF7)(void);
__declspec(dllexport) void dllFunction(void)
HMODULE hModule = LoadLibrary("application.exe");
FARPROC pFunc = GetProcAddress(hModule, "appli_printf7");
if(pFunc)
((APPLI_PRINTF7)pFunc)();
else
printf("error = %d\n", GetLastError());
return;
and here is the code of application.exe
#include <Windows.h>
#include <stdio.h>
typedef void(*DLL_FUNC)(void);
__declspec(dllexport) void appli_printf7(void)
printf("7");
return;
int main(void)
HMODULE hModule = LoadLibrary("dll.dll");
FARPROC pFunc = GetProcAddress(hModule, "dllFunction");
((DLL_FUNC)pFunc)();
return 0;
I compiled dll.dll once and for all with LabWindows (8.5), and I compiled exactly the same code for application.exe with LabWindows (8.5) and Visual Studio 2013.
It works with Visual Studio (the dll finds appli_printf7 and 7 is printed on the screen), but doesnt with LabWindows (the dll does not find appli_printf7 and prompt the error 127 (The specified procedure could not be found.)).
I used Dependency Walker (and dllexp to confirm) to find out that appli_printf7 is actually NOT exported with LabWindows, and is exported with Visual Studio.
Therefore, it is normal that the dll can't find the symbol if it is not exported.
My questions are :
- Why is that so ???
- Is there a setting to set in order to make LabWindows export symbols marked by __declspec(dllexport) for .exe projects ?
- Is this a problem fixed with a newer version of LabWindows ?
- My dll is actually a plugin to my application. If I can't load symbols from my application, how can I provide an API for my dll in order to make generic functions available to it ? Is there a workaround for it ?
Edit : I tried with LabWindows 2012, same problem..
Thanks in advance

Cannot export crystal report in excel format from crystal report viewer

This problem occurs on only one workstation.
Open Advanced Reports > Enter workorder # > Click on 'workorder work(uninvoiced)' > Work order opens.
Click on icon "Export report"
Save as type: change to .xls
Error: Crystal Report Windows Forms Viewer. Error in file
SAP.......rpt:
Error detected by export DLL:
Export failed.

Try adding c:\Program Files\Business Objects\BusinessObjects Enterprise 12.0\win32_x86 to your windows enviroment variable PATH then restart.

Is there a way to determine all the function of a certain dll in Labview?

Hi, I am Marlon. Is Labiew capable of determining all function in a certain DLL?

Hi Marlon.
There is a example in Labview Zone ( look for "Get DLL Exports") that lists names of all functions in a dll 32.
Hope it helps
Alipio
"Qod natura non dat, Salmantica non praestat"

Using mingw to make a .dll for use in labview ?

I have seen some posts on this, but none of them take it all the way from C code to configuring the shared library node...
My code is heavily based on this:
http://forums.ni.com/ni/board/message?board.id=170&thread.id=171056
Here are my files:
//reedll.h
#ifdef BUILD_DLL
// the dll exports
#define EXPORT __declspec(dllexport)
#else
// the exe imports
#define EXPORT __declspec(dllimport)
#endif
// function to be imported/exported
EXPORT void tstfunc(int A, int B, int C);
and:
//DLL_Test.c
#include "reedll.h"
EXPORT void tstfunc(int A, int B, int C)
C = A + B;
Its meant to be as bare bones as I can get it. No crazy pointers or anything.
I compile as follows usin MinGW:
g++ -c -DBUILD_DLL DLL_Test.c
g++ -shared -o tst.dll -Wl,--out-implib,libtstdll.a DLL_Test.o
And it appears to compile fine.
When I go to import the .dll into the shared library node the "Function Name" field is garbled and says "Z7tstfunciii" instead of "tstfunc". Needless to say the shared library function icon that results doesnt work

You should tell the mingw compiler to not name mangle the symbols. Most likely you use a cpp file enxtension and then mingw as Visual C will invoke the cpp compiler instead of c which by default name mangles function names.
If you want or need to use cpp, you can also try to declare your exported symbols like this:
#ifdef __cplusplus
extern "C" {
#endif
EXPORT void tstfunc(int A, int B, int C);
/* all the other function prototypes you do not want to be mangled */
#ifdef __cplusplus
#endif
Not sure if __cplusplus is defined by mingw, if not you have to find how it indicates that C++ mode has been invoked.
Message Edited by rolfk on 03-24-2010 02:48 PM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

How to use COM DLL in LabWindows

Hello
I have a COM .dll which looks like that when opened with dll export viewer:
I would like to use the Get4AxisPos function in LabWindows.
I understood that, as I only have the .dll, the only way of calling these functions are with the LoadLibrary() and GetProcAddress() functions.
My problem is that the Get4AxisPos function is not of type Exported Function but COM Method so I don't know how to use it in my LabWindows project!
My questions are: Is it possibleto use this dll in Labwindows? If yes how?
Thanks
Solved!
Go to Solution.

Hi ,
I am new to C++ and COM .
i need to implement a client application in C(lab windows CVI) , server is a c++ COM object.
steps followed by me
---> accessed the registered COM object with Labwindows CVI active x controller template,output was a c file which is implementation of the class names in COM (interfaces).
I can use majority of the functions directly from the generated, but i need to implement some event functions like message box events and then use it.
I have seen one method of accessing in C++ client sample ,
which implements Queryinterface function...takes the IID_Unknown as input and returns interface pointer(inhereted static_castof the required class, uses static_cast for that) as output.
when i try to follow up the same in c , i am lost with the inheritance concept.
In short i need to send IID Unknown to the Queryinterface function and should get the interface pointer of message box type or other class type ...
Sorry for the long mail,Please guide me
Thanks in advance ,
Satish

Call multiple functions from same dll with call library function

hi,
i am working on a project in wich we need to make a UI to read out a sensor network.
the UI should be usable in any project, but every node needs a different piece of code depending on the type of sensor with wich it is equipt.
so i need to be able to call different pieces of code when i need them, and still be able to use the UI in future projects with possibly new types of node we now don't have.
so someone told me to use DLL's, cause then i would be able to call the code i need the moment i need it.
but i have never worked with DLL's (just learned about this option 3 day's ago) so i have a question.
i know i can dynamicly change the DLL i call with the call library function, but can i dynamicly change the function i call from that DLL ?
or do i have to put a new call library function for each function i want to call, even if its from the same DLL ?
kind regards,
stijn

nazarim wrote:
ok so there is no (easy and ubderstandable) way for me to dynamicly change wich function i want to call from a certain DLL.
but now i started wondering, the path on the call library function is not ment to dynamicly change a DLL
but it does work so, if i am carefull, can i use it for that purpose or will labview give me a series of problems once i start using it in larger programs ?
Thepath on the Call Library Node can be used to load a different DLL. Obviously since you can't change the function name your other DLL would have to export exactly the same function name and of course with the same parameters. This is seldom the case so it is not the main use of the path input to the Call Library Node. It's main use is as indicated to load DLLs at runtime rather than at load time of a VI. So that an application can run even when the DLL is missing, until the moment the functionality from that DLL is needed.
If you can make sure that all your DLLs export the same function name with the same parameter you can use the Call Library Node to call into different DLLs through the path input. If however you would need to call different function names you would have to resolve to some DLL which does do the dispatching and invocation using LoadLibrary() and GetProcAddress(). But unless you need to go with DLLs for some reason using the Call By Reference Node can give you an even more flexible approach.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

How to integrate third party API and DLL

Dear sir/Madam
How can i integrate the third party high level API and DLL into my DLL, project keeping in view that all their functions and their definitions kept hidden. i have tried it but when importing the functions in the DLL and export the high level functions, compiler demands their declarations and prototypes.
Is their a way to hide all these high level functions and still utilize them.
thanks, regards
Zafar

Hi Matrix39,
The compiler will still need the proper prototypes for the functions called in the third party DLL to compile your DLL whether you are using explicit or implicit linking to call the functions. Declaring these prototypes in your DLL does not mean they will be exported by your DLL. The functions exported by your DLL can be configured by navigating to Build»Target Settings in CVI. From here you can configure what functions your DLL exports by clicking the Change... button in the Export section. There are several options for specifying the functions including using header files and manual export declarations. See the CVI Help for more information.
Justin D
Applications Engineer
National Instruments
http://www.ni.com/support/

C++ build error with LabVIEW DLL

Hi, I'm a student at UC Irvine learning to use LabVIEW. I am working on a practice project for which I have to use a PID system to control the temperature of an object. Things are starting to get a little messy with nested control statements, loops, etc., so I figured I'd export a LabVIEW DLL with all the hard to code stuff, such as interfacing with my instruments, and plotting data or whatever, and do the number crunching and keeping track of stuff in C++.
The DLL file I made in LabVIEW went off without a hitch as far as I can tell, but when linking it to my C++ test program (which at this point is just including the LabVIEW's .h file for the DLL and an empty main() function), I get a lot of build errors. I am using Dev-C++ which uses g++ to compile the code.
Here is a pic of my build errors:
Solved!
Go to Solution.
Attachments:
LabVIEW_compile_error.JPG ‏184 KB

Normal windows apps are not as forgiving about where you can put your DLL as LabVIEW. You have to have a DLL either in the direcotry where the executable file itself resides (that would be your build directory, not the source directory), the windows or system directory, or any directory that is set in the PATH environment variable. Anythin else will most likely not work, or at least not reliably.
No need to add the cintools directory into your include file paths nor the library file paths. you would only need that if you decided to let the DLL export native LabVIEW data types in which case you would need the LabVIEW manager functions to prepare the correct data buffers.
Rolf Kalbermatter
Message Edited by rolfk on 07-30-2009 07:49 AM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Dll import

dear forum.
I cant understand a base matter about dl.
I know how to import dll in VS and use. But in some code, i read programmers need to
use in C++ the LoadLibrary and GetProcAddress
for reference to internal function .
Why
Thanks

On 30/03/2015 16:16, Robiberto wrote:
I cant understand a base matter about dl.
I know how to import dll in VS and use. But in some code, i read programmers need to
use in C++ the LoadLibrary and GetProcAddress for reference to internal function .
Why
I'm not sure what you exactly mean by "reference to internal function".
But I'd like to share a possible scenario with you.
Suppose that you have an application supporting some form of extensibility architecture via plugins.
Each plugins can be implemented using a separate DLL.
And, of course, you don't want to rebuild your application from scratch with every plugin's .lib file.
Suppose that each plugin requires initialization, and to do so the plugin DLL exports a "PluginInit" function.
Your application could scan the content of a given directory (e.g. a folder named "plugins" under the application's folder), and, for each plugin DLL found, it could use LoadLibrary() and GetProcAddress() to get access to PluginInit() for each
DLL, and call it to perform plugin initialization, for each DLL.
Giovanni

Calling DLL in CVI2013

Sorry for this basic question but I am not very familiar with external DLL's...
I have some older code where I used
typedef void ( __stdcall *fp_SPNDLdllTYPE )( double *, double *, double *, double *, long *, char *, long );
I need this to assign the address of a function in the DLL using LoadLibrary and GetProcAddress.
Everything was fine until I recompiled this code with CVI2013,.the address obtained now is zero... ?
Since the compiler has changed I tried both default calling conventions in the Build options, but it did not help...
What do I need to change? Thanks!
Solved!
Go to Solution.

That's very odd. Since the CVI compiler has played no role in building this DLL, I can't imagine what difference 2013 vs. 2012 could be making.
So, what you're saying is that you can run that exact code with CVI 2012, and GetProcAddress works fine, but when you run it with CVI 2013, while using the same exact DLL, it does not? Is it possible that you could have more than one copy of this DLL in your hard-drive, and the search path used by LoadLibrary could be finding different copies (I believe the current working directory affects the search). To confirm this, you can use GetModuleFileName to make sure that you're loading the DLL from the same place. (By the way, is the name of the DLL really "rp"? Not "rp.dll" or something?)
Do you have access to Visual Studio? If you do, you could try running this code from Visual Studio to see if it makes a difference. It would also be useful to try the dumpbin.exe utility that comes with Visual Studio to make sure that SPNDLdll is really being exported:
>dumpbin /exports foo.dll > exports.txt

HELP! RETURN CLOB from External DLL

Hi
I am working on an External DLL using OCI. Basically, PL/SQL
calls an
External DLL to process the data and then returns LOB back to
the PL/SQL
procedure. Inside the DLL, I created a Temporary lob to process
the data.
The error is prompted from PL/SQL:
SQL> exec isdb.test_clob;
Before original length=10
ORA-24805: LOB type mismatch
ORA-06512: at "ISDBSVR.ISDB", line 24
ORA-06512: at "ISDBSVR.ISDB", line 29
ORA-06512: at line 1
So far I know that error is caused by the return from PLS_CLOB
is not clob.
"After_original := PLS_CLOB(before_original); {you will see more
code in the
below}" However inside the DLL, I have defined OCIClobLocator
and
OCI_TEMP_CLOB to carry the CLOB data.
I have found the following observations:
1. If I change everything to blob, it works fine. (such as
OCILobLocator,
OCI_TEMP_CLOB and all variables in PL/SQL)
2. If I run the same DLL and PL/SQL in 9i, it works fine (clob
too)
I guess it would be a bug for clob, please help to check thanks
-- CODE - PL/SQL
CREATE OR REPLACE PACKAGE BODY "ISDBSVR"."ISDB"
as
Function PLS_CLOB(var_clob in clob)
RETURN clob IS
EXTERNAL LIBRARY bb
WITH CONTEXT
NAME "Encrypt_Blob"
LANGUAGE C
PARAMETERS
CONTEXT,
var_clob,
var_clob INDICATOR SB4,
RETURN INDICATOR SB4
PROCEDURE TEST_CLOB IS
before_original cLOB;
After_original cLOB;
CHAR_TO_CLOB varchar(200);
bsize int;
BEGIN
CHAR_TO_CLOB := 'AAAAAAABBBBBBCCCCCCC';
dbms_lob.createtemporary( before_original, TRUE );
DBMS_LOB.write( before_original,10,1,CHAR_TO_CLOB);
bSize := DBMS_LOB.GetLength(before_original);
DBMS_OUTPUT.PUT_LINE('Before original length='||bSize);
After_original := PLS_CLOB(before_original);
bSize := DBMS_LOB.GetLength(After_original);
DBMS_OUTPUT.PUT_LINE('After original length='||bSize);
dbms_lob.freetemporary(before_original);
END;
END ISDB;
/* CODE - DLL */
EXPORT OCILobLocator * EncryptBlob(OCIExtProcContext
*with_context,
OCILobLocator *plaintext2,
sb4 pt_indicator2,
sb4 *ret_indicator
{ FILE *fp;
OCIClobLocator *cipherbb;
ub4 amount;
ocictx oci_ctx;
ocictx *oci_ctxp = &oci_ctx;
status = OCIExtProcGetEnv(with_context,
&oci_ctxp->envhp,
&oci_ctxp->svchp,
&oci_ctxp->errhp);
status = OCIDescriptorAlloc(oci_ctxp->envhp,
(dvoid **) &cipherbb,
(ub4) OCI_DTYPE_LOB,
(size_t) 0,
(dvoid **) 0);
status = (int) OCILobCreateTemporary(oci_ctxp->svchp,
oci_ctxp->errhp, cipherbb,
OCI_DEFAULT,
OCI_DEFAULT,
OCI_TEMP_CLOB, OCI_ATTR_NOCACHE,
OCI_DURATION_SESSION);
amount = 6;
status = OCILobCopy(oci_ctxp->svchp,
oci_ctxp->errhp,
cipherbb,
plaintext2,
amount,
(ub4) 1,
(ub4) 1);
*ret_indicator = OCI_IND_NOTNULL;
OCIDescriptorFree((dvoid *) cipherbb, (ub4) OCI_DTYPE_LOB);
return(cipherbb);

In what database version did you observe the problem?
Thomas

Access ni4882.dll with Qt and MinGW

I have to control some electric loads and power supplies over GPIB. We use Qt 4.7.4 with MinGW 4.4 (32-bit) on Windows 7 64-bit.
The packet NI-488.2 GPIB Drivers packet 3.0.2 for Windows 7 64-bit is installed. The GPIB Troubleshooting Utility tool shows "pass" and the Measurement & Automation application can connect to the board and talk to an intrument. So far so good.
Now I want to write an application to use the NI4882.dll (3.0.0.49153). Unfortunately, there are just object files for Microsoft and Borland compilers and no lib file.
So we generate a def file from the ni4882.dll with:
pexports -h ni4882.h ni4882.dll > ni4882.def
-ni4882.def-
LIBRARY NI4882.dll
EXPORTS
?compareVersion@nGPIBAPI_NI4882@@YGXABVtSSVersion@@0AAJPBD@Z
?getCurrentVersion@nGPIBAPI_NI4882@@YG?AVtSSVersion@@AAJ@Z
?getOldestCompatibleVersion@nGPIBAPI_NI4882@@YG?AVtSSVersion@@AAJ@Z
AllSpoll@12
DevClear@8
DevClearList@8
Then generate the lib with:
dlltool -k -D ni4882.dll -d ni4882.def -l libni4882.a
Now, I've build a small test program in Qt.
-.pro file-
INCLUDEPATH += $$PWD/include
LIBS += $$PWD/lib/libni4882.a
-.cpp file-
#include "ni4882.h"
void MainWindow::Init()
int dd = idev(0,3,0,T10s,1,0);
if(Ibsta()&ERR)
    Err(tr("Unable to open board:ibdev=%1").arg(dd));
if( ibonl(0,0)&ERR)
    Err(tr("Unable to close board"));
void MainWindow::Err(QString message)
switch(Iberr())
    case 0:
      message.append("(EDVR - System error)");
    } break;
qDebug("Error : %s\nibsta = 0x%x iberr = %d\n",
    (unsigned int)Ibsta(), (int)Iberr());
The source code will be compiled and linked without an error.
But if I run it, the output is:
Error : Unable to open board: ibdev=32768 (EDVR - System error)
ibsta = 0x8000 iberr = 0
Error : Unable to close board (EDVR - System error)
ibsta = 0x8000 iberr = 0
So, the question is: What is wrong? Why do I always receive this EDVR error. I also tried SendIFC(0) with the same result.
With the GPIB Interactive Control tool, I can communicate with my instrument and the NI I/O Trace logs it. But I can't see logs in the Trace tool from my application. Is this an indication?
Any ideas?
Marko
Solved!
Go to Solution.

Hi to all,
after some questions about using the GPIB library with Qt, I've written a step by step description to create object files for MinGW:
1. Create a folder and copy the "gpib-32.dll" from the "C:\Windows\System32" ("C:\Windows\SysWOW64" in Win7) to this folder.
2. Copy "ni488.h" from "c:\Program Files (x86)\National Instruments\Shared\ExternalCompilerSupport\C\include\". (Not ni4882.h!)
3. Load PExports (my version is 0.44) and put the exe in your folder to. I do not have a URL to load this tool but should be easy to find. It's freeware.
4. Copy dlltool.exe from "c:\QtSDK\mingw\bin\" to your folder.
5. Create a batch file "1 - build def file.bat" with the content: "pexports -h ni488.h gpib-32.dll > gpib.def"
6. Create a batch file "2 - build lib file.bat" with the content: "dlltool -k -D gpib-32.dll -d gpib.def -l libgpib.a"
7. Start the batch file "1 - build def file.bat" to create the def file "gpib.def"
8. Start the batch file "2 - build lib file.bat" to create the library file "libgpib.a"
9. Copy "gpib-32.dll" and "libgpib.a" to your software project. I created the subfolder "lib" and copied the files into.
10. Copy "ni488.h" to your software project. I created the subfolder "include" and copied the file into.
11. Into your PRO file type:
# Include the NI 488.2 library
INCLUDEPATH += $$PWD/include
HEADERS += include/ni488.h
LIBS += $$PWD/lib/libgpib.a
12. In your source code type:
#include "windows.h"
#include "ni488.h"
bool InitializeGPIBBoard( )
bool isStarting = false;
int boardID;        /** @brief Board id. */
QString boardName; /** @brief Board name. */
int boardDescr;     /** @brief Board descriptor. */
// Get board ID
SendIFC(boardID);
if( ThreadIbsta() & ERR )
    ErrorHandling(tr("Unable to open board"));
    return isStarting;
// Open and initialize a board or a user-configured device descriptor
wchar_t *aName = new wchar_t[boardName.size()+1];
m_para.boardName.toWCharArray( aName );
aName[boardName.size()] = 0;
m_para.boardDescr = ibfind( aName );
delete []aName;
// The board is the System Controller.
if( ibconfig( boardDescr, IbcSC, 1 ) & ERR )
    ErrorHandling(tr("Unable to set the board to System Controller"));
    return isStarting;
// Assert interface clear.
if( ibsic( boardDescr ) & ERR )
    ErrorHandling(tr("Assert interface clear"));
    return isStarting;
// aso.
isStarted = true;
return isStarted;
13. Be happy! :-)
I hope that helps. If you have problems, please write me a message or post on this board thread.
Gruß und viel Erfolg!
Marko

Cvirte.dll and Windows Vista

Hi everyone,
I used to have .DLL compled in LabView 7.1 that worked just fine in Windows XP. Now, I have rebuild it for Windows Vista. I have installed LabView RuntimeEngine 8.51.
It's not working.
Can you point out why?!
However I was wondering what happened to cvirte.dll, that I cannot see anymore in my Vista OS. DLLs should work without it?

I would start over and create a project from scratch and create a new build specification for the DLL. Add one function at a time and get them to work.
Is it possible post a screenshot of a DLL export function prototype and the corresponding VI blockdiagram and connector pane?
Message Edited by andre.buurman@carya on 10-17-2008 03:03 PM
Regards,
André
Using whatever version of LV the customer requires. (LV5.1-LV2012) (www.carya.nl)

DLLs - Export of VI mandatory

Similar Messages

Maybe you are looking for