Dereferencing a pointer from a Windows API call within labview

[smercurio_fc]

---

@LostFound wrote:

After stepping back and looking the challenges with dereferencing pointers within labview,  it seems best to get the boolean status I need (is the handle valid - basically is the file open) by just writing a C function, including an API, testing the file handle in C then returning the boolean result and pass it into labview through a call library function node.

---

Let me guess. You're a C programmer. Right?

As I noted in a Rube Goldber response, you can either:

(a) turn left, hop across the intersection, go down to the subway, take the subway north, go up the subway stairs, take the trolley to 54th street, get off, take the bus down to 5th, hail a cab, get out, walk three blocks, hop onto the helicopter that's waiting, get off at the rooftop, take the elevators down, and then walk out the front door.

-or-

(b) just cross the street (after looking both ways) by simply using the Open File function as suggested.

Your choice.

[nathand]

As several other posters pointed out, you never need to dereference the pointer to check if the function returns INVALID_HANDLE_VALUE.  A pointer is just a numeric value, and that numeric value is -1 when you don't get a valid handle.  You seem to be under the impression that the function returns a pointer to a pointer to a memory location holding the value of -1, and that's not the case (why would CreateFile allocate two memory locations just to store the value of -1, when it can return that value directly?)  All you need to do is see if the return value from CreateFile is equal to -1.

[LostFound]

Turns out I was using an open file in NotePad to test all this which will never give an invalid handle (Windows API) or  an open file error (labview  fileIO-->open/create/replace file).  The only way I came up with so far to detect an open txt/log file on a share drive (opened by a user using notepad) is by trying to rename the directory which fails if any files are open.  I can do this with a movefile() (really it should be called rename) windows API call within labview.

If you have another technique I would be interested.

[smercurio_fc]

http://zone.ni.com/reference/en-XX/help/371361G-01/glang/move/

If you're going to write C code why are you even bothering to write in LabVIEW?

[rolfk]

It seems you figured out that the handle returned by Create File is not to be referenced at all since it is simply a pointer whose content should be treated private to the Windows kernel implementation. CreateFile() returns a pointer sized integer as far as LabVIEW is concerned, which can be passed to other windows API functions that accept a HANDLE. What it contains is not only private to Windows but can completely change between Windows versions. If this pointer value is -1 (of 0xFFFFFFFF on a 32 bit system and 0xFFFFFFFFFFFFFFFF on a 64Bit ssytem) then that's the canconical indication of an error in the CreateFile() function. No dereferencing necessary nor even allowed.

You can only really easily detect if a file is open when that file was opened with at least one limititation in its sharing flags (FILE_SHARE_WRITE and/or FILE_SHARE_READ not set). If an application allows read and write to other applications when it opens the file, trying to open it by another application simply works. I'm also not aware of any other direct way to detect that an application has already opened a file. FileChange events obviously won't work because they can only detect events after the event handler was registered for that file. The only receommended way I have found to see who has opened a particular file is by enumerating all processes and from there all handles each process has open and then search from there for your particular file. Quite a heavy weight abproach to see if a file is opened by another process already.

As to naming Move the way it is: The Windows API function to rename a file is also called MoveFile(). While that is certainly not the reason why LabVIEW calls it Move too (if any API at that time has influenced the naming in LabVIEW it certainly was the MacOS API and nothing else) it really is mostly irrelevant. Unix calls the according function indead rename() but so what?

If the file stays in the same directory we tend to look at it as a rename, otherwise a move, but the underlaying operation in terms of the file system is really exactly the same.

[GregFreeman]

---

@smercurio_fc wrote:

If you're going to write C code why are you even bothering to write in LabVIEW?

---

I was wondering the same thing. A link that may help in these difficult times.

[LostFound]

rolfk - Thanks for all the details in your post - it helped.

[LostFound]

smercurio_fc - Was trying to avoid using C all together since my project is all in labview which is the requirement of my larger project.

.

[D*]

Rolf, I just found out that I was getting bitten by treating the file HANDLE as a 32-bit number (on 64-bit windows), do you know in general when HANDLE is a pointer and when it's just a 32-bit number? 

The dev note below makes it seem like HANDLE is usually 32-bit.  Is it okay to treat all HANDLE as 64-bit just to be safe?

32-bit and 64-bit Interoperability
https://msdn.microsoft.com/en-us/library/windows/desktop/ee872017(v=vs.85).aspx

Thanks!

[rolfk]

---

@D* wrote:

Rolf, I just found out that I was getting bitten by treating the file HANDLE as a 32-bit number (on 64-bit windows), do you know in general when HANDLE is a pointer and when it's just a 32-bit number? 

Doesn't surprise me. The implementation of a HANDLE is implementation private and not documented anywhere officially. There are many different subsystems that use HANDLEs in one way or the other and generally it can be either an index into a module internal table, a magic value or a real pointer, and that could even change between Windows versions. Microsoft has sort of documented that GDI handles and other UI related handles are supposed to be 32 bit safe (that can be so even if it is in fact a real pointer since the GDI objects are all allocated on a reserved heap that gets allocated during Windows GDI initialization) even on 64 bit system, but that is not true for every handle that Windows uses and definitely not for 3rd party software that uses handles.

The definition of a HANDLE in Windows is void *, that means a pointer to some memory. What is inside the memory, and if there is a real pointer stored or a magic value, is implementation specific and not generally something the user of an application should have nor want to care about!

The dev note below makes it seem like HANDLE is usually 32-bit.  Is it okay to treat all HANDLE as 64-bit just to be safe?

32-bit and 64-bit Interoperability
https://msdn.microsoft.com/en-us/library/windows/desktop/ee872017(v=vs.85).asp 

---

No, in 32 bit Windows it is definitely always a 32 bit value. In 64 bit Windows it is in fact a 64 bit value but for some HANDLEs it may be ok to only use the lower 32 bit and leave the upper bits undefined, depending what the underlaying module uses.

In terms of LabVIEW this means following:

1) The parameter to the Call Library Node should be ALWAYS defined as pointer sized (unsigned) integer.

2) In the LabVIEW diagram you should use a 64 bit (unsigned) integer to pass that handle around in order to guarantee that all the data is actually passed around from one Call Library Node to the next and real pointers are not suddenly truncated from treating them as 32 bit value on the LabVIEW diagram.