Rolf Kalbermatter

Hey, don't tell me you have white hair! In my age that is something that comes to men naturally but for you I had thought that will take some more time :-) Good luck and may IVision still bring you some compensation for whatever you've put into it. Rolf Kalbermatter

First: GetIndirectFunctionHandle and friends were only meant and available for LabVIEW for Windows 3.1. Second: In order to call a function over a pointer variable, this pointer variable must be properly typed either through the declaration itself or a typecast at the point of call. Otherwise the C compiler can't know how to pass the parameters and what to expect as return value. if (!(UsernameCStr == (char *)DSNewPtr(*Username)+1)) {cinErr = mFullErr; goto out; } will allocate not what you think it does. It will use the pointer value in the handle as length indicator and attempt to allocate potentially a huge amount of memory running out of memory quite soon. You should make this read if (!(UsernameCStr == (char *)DSNewPtr(LStrLen(*Username))+1)) {cinErr = mFullErr; goto out; } and even better would be to allocate a cleared memory area with DSNewPClr(). Instead configuring a CallLibraryNode with advapi32.dll, LogonUserA, stdcall calling convention, the string parameters as C string pointers and the two constants as uInt32 and the last one as an uInt32 passed as pointer, simply should work fine. Last but not least you will leak a handle here with LogonUser returning the phToken that never gets closed. Rolf Kalbermatter Download File:post-349-1140011772.vi

I didn't now that you didn't know about LabSQL then. To me it had seemed the most efficient way to build on LabSQL and improve and extend on that one, seeing that you have mostly the same licensing philosophy as the original author of LabSQL. Would have saved you quite some time ;-). And improving and extending an existing Toolkit probably just as much gets you into learning the basics of it. Rolf Kalbermatter Why should anybody want to do that? Database Access over ADO works well, is supported on many more machines than .Net (.Net only working under Windows 2000 after installing an update) and most database drivers are either ADO or ODBC based. Using .Net would just add an extra complexity level to the already involved picture of ODBC driver->ODBC manager->ADO-ODBC gateway->ADO system->ADO->ActiveX interface. I can think of many better ways to spend CPU cycles, memory, and HD space. Rolf Kalbermatter

I can think of a few not so complicated runtime checks that would disallow the workaround found by Stan and if I can think of it, the guys at NI can for sure as well. If they find it necessary to worry about that one, I'm however not sure. Rolf Kalbermatter

While the registry might hold this number somewhere it is not terribly difficult to hook the registry access and return to a specific applciation different information than to the rest of the system. It definitely gives an attacker an extra angle to get in, and if you consider HD serial numbers not secure enough you must envision a dedicated hacker and not just the joe average user that knows little more than how to start an installer. Of course you can even fool a tool that gets the information directly from the BIOs but that really requires some assembly and protected mode knowledge, although that knowledge is not something strange among real hackers. Rolf Kalbermatter

Id2x I have just a question? Isn't LabSQL (and incidentially the Database Connectiivity Toolkit from NI) not also using ADO? If so what does your solution add to this? Rolf Kalbermatter

What has this to do with the original post? Thread hijacking is not nice! Rolf Kalbermatter

I for one don't but I happen to have played with the functions in LabVIEW 7.1 recently and probably come across a possibility similar to what Stanislaw has done in his other thread where he handed us the ladder to reach the toys, NI in its universal wisdom had put on a very high shelf. But I also can envision that NI might try to close that loop hole too, putting even the execution of certain nodes behind the licensing. Rolf Kalbermatter

Yes, scripting is now not anymore controlled with an ini file setting, but through the license manager. (In fact it seems LabVIEW still wants to have an ini file setting but it will only check this setting after you have installed a valid scripting license, and no it is not the same ini file setting as in the past :-( Rolf Kalbermatter

The MAX API is private and undocumented. Nobody outside of NI can write drivers that integrate with MAX directly (aside from the standard OS drivers such as COMM for serial ports) that integrate in MAX. I doubt that there are many manufactuerers that have such an integrated and feature rich configuration interface for thier hardware as what you get with MAX. Rolf Kalbermatter

Not exatly sure as it is a long time ago when I investigated scripting. But if my memory serves right you will have to walk through the rather large LabVIEW object hierarchy to get to the wire in question and then using a Method (or was it a Property) node you can set the breakpoint on that wire. As to how to walk the object hierarchy of a VI, there have been several examples here on Lava but it is a pain indeed. The problem is, I can not see another possibility to implement this object model in a way that would be much easier to walk and understand without loosing tons and tons of possibilities. Personally I think this is the main reason NI has not decided to make this feature available to outside people since they can envision a load of support requests if that feature gets made public. Rolf Kalbermatter

I'm posing a possible explanation to the problem. It seems that your error message contains a path that is only partly complete (breaking at the space in National Instruments). Obviously at some place the path construction is not done correctly and if you pass a path to a command line tool containing spaces and that path is not embedded in double quotes the command line tool will see the path as multiple command line arguments resulting in each argument to be an invalid path. I wasn't saying that this is something you did wrong but that it is something with lvmetadiff and or other tools involved. Since they are however all Open Source and available in source code there is no reason why you shouldn't be able to go and try to fix the problem for yourself. Rolf Kalbermatter

This won't work. The CIN node or shared library is still running in the application context and as such has no direct access to the protected kernel resources to whom the Port IO adresses belong. You have to extend your kernel itself to allow port access either by a port IO kernel driver that translates your port access requests to the actual hardware access on behalf of your application or by an expansion to the kernel with a system call to manipulate the IO permission map. In the first case you call your device driver and pass it the IO adress, access mode and data and it does then do the actual port read or write for you and in the second case you do a system call to that new kernel function to tell it to modify the port IO permission map for your process to allow direct access to specific IO adresses from your application process. Rolf Kalbermatter

An IMAQ runtime is

I'm afraid you can't. An LStrHandle is a special LabVIEW datatype and there exists no direct .Net equivalent for it. As you can see in extcode.h, it is a pointer to a pointer to an int32 followed by the actual (non-unicode) character string. As such it is not even directly a long Pascal string (although with a pointer to such a beast you could simulate it) but I doubt that .Net even would support that one. Rolf Kalbermatter

A C compiler does just that. You use the sizeof() keyword for this and that will calculate the compile time size of any datatype including structures and use that value in the compiled code. LabVIEW obviously does not have C parsing capabilities so can't do anything for you with that header file. Rolf Kalbermatter

LabVIEW scripting in LabVIEW 8 is put behind the license manager. There is currently no way to get LabVIEW scripting to work in LabVIEW 8 except for NI guys. Rolf Kalbermatter

Embedded space problems!! The path to the files should be enclosed in double quotes. Now where is the problem? lvdiff? shell extension configuration?? Rolf Kalbermatter

I'm not aware of videocap but instead avicap. If you mean that you are probably using the WebCam library from Pete Parente. Avicap is an old API from Windows 3.1 days that is based on Video for Windows (and a vfwwdm driver allows it to also access WDM drivers indirectly) but avicap has no provisions for really configuring the video device as there wasn't much to configure programmatically back in those days where it was common to have to set jumpers on the board for a lot of things. The only interface that allows real configuration programmatically is the DirectX/WDM based interface and your best bet is to use an ActiveX interface for this either buy it or roll your own. You might also want to look into Irene He's IVision library, but that is also not really free of charge although a little cheaper than IMAQ Vision. Rolf Kalbermatter

I think you messed up your LabVIEW version. Up until LabVIEW 7.0 the lvanlys.dll was a self contained DLL you could easily move together with your labview files. In LabVIEW 7.1 they changed that library to use the Intel Math Kernel Library instead for the number crunching work. This is actually a quite useful move since the MKL is a recognized standard about how to do numerical analysis. However the MKL is not part of LabVIEW and comes with its own installer that does some registry settings so lvanlys.dll can find it. In order for MKL to be properly installed and for lvanlys.dll to find it you have to install it. You can do so by creating an installer in the Application Builder and going into the Installer Settings tab->Advanced... button. Make sure you enable "LabVIEW Runtime-Engine" and "Analyze VIs Support". Other things are usually not really necessary but that of course depends on your application. Now you can just run that installer on any computer and you should get with a proper installation of your LabVIEW executable AND the LabVIEW runtime AND the MKL. Rolf Kalbermatter

You lost me. Where did you see that you get the size from somewhere? What are you trying to say? Rolf Kalbermatter

Set those "Boardxx = 1" to "Boardxx = 0". This will disable NI-VISA from attempting to search for GPIB devices. Set "DisableAutoFind = 1" Set those "Interfacexx = 1" to "Interfacexx = 0". This will disable NI-VISA from attempting to search for HP/Agilent GPIB interfaces. I'm usually explicitedly not installling Tulip VISA since I have no plans on using HP GPIB interfaces anyhow. You could try to set "SynchronizeAllVxi11 = 0". That should speed up things too since VISA won't even attempt to try to look for VXI11 devices on the TCP/IP bus. You can write a VI that uses the Config File functions to explicitedly set those config settings. Attached VI does disable all GPIB interfaces, so you may need to modify it if you require a GPIB interface. USually it would be enough to only enable the first GPIB board (Board0), since you seldom will have more than one. Rolf Kalbermatter Download File:post-349-1138873852.vi

USB really isn't something you should use when you want to rely on it that it runs for weeks uninterrupted. While the idea of USB is nice there are a myriad of things which can and often do go wrong. The first and most obvious problem are the devices itself. There are many USB chip solutions out there that have simply more or less grave bugs in the silicon. They are sometimes getting fixed in later versions of that chip, if the manufacturer actually cares enough to fix its silicon instead of just releasing yet another silicon design with new bugs in there. Then the device drivers of those devices, quite often they are more or less taken over entirely from the development kit of the silicon manufacturer despite of notices all over the place that the software is only provided as an example of how it works and shouldn't be used in production quality designs. Then a quite common problem too are the actual USB chip bridges in the PC themselves and the according drivers. Nowadays those PCs are designed in a matter of months and often the newest chips are used despite that they have sometimes bugs too and their drivers are not yet mature. Maybe it is possible to patch the problems later on with a driver update and maybe the bug is not really fixable in software, which with most PC manufacturers nowadyas means bad luck for the end user. Basically if you want to use USB for uninterrupted long term data acquisition you will have to evaluate both the data acquisition hardware as well as your PC platform very carefully before doing so. USB for life supporting devices is definitely something you should never attempt to do unless you fully control the entire chain from controller software and hardware to the device software and hardware. Rolf Kalbermatter

Maybe some guys came out of a long winter sleep and still think things are done the way as in old DOS days, not wanting to understand that there are nowadays cheap ready to run hardware solutions that cost less than the material you would need to build your own (not to talk about the time you will need to build your own). Rolf Kalbermatter