This looks interesting

[Neil Pate]

Obviously I don't know what I am talking about, but could this in the future be used to simplify configuring Win32 API DLL calls in LabVIEW?

https://blogs.windows.com/windowsdeveloper/2021/01/21/making-win32-apis-more-accessible-to-more-languages/

[ShaunR]

4 hours ago, Neil Pate said:

Obviously I don't know what I am talking about, but could this in the future be used to simplify configuring Win32 API DLL calls in LabVIEW?

https://blogs.windows.com/windowsdeveloper/2021/01/21/making-win32-apis-more-accessible-to-more-languages/

Maybe make the DLL import wizard actually useful.

Not sure why they are doing this though. .NET was supposed to be the next generation of Win32 API's. I guess they got fed up of migrating the functionality.

I used to have a program for Windows WMI queries that did something similar. It wasn't one that I wrote but was a tool intended for Borland languages that meant you could query the WMI database live and create the queries in C++ and Delphi prototype snipits. This looks similar for Win32 API's.

[Rolf Kalbermatter]

21 hours ago, Neil Pate said:

Obviously I don't know what I am talking about, but could this in the future be used to simplify configuring Win32 API DLL calls in LabVIEW?

https://blogs.windows.com/windowsdeveloper/2021/01/21/making-win32-apis-more-accessible-to-more-languages/

The potential is there and if done well (which always remains the question) might be indeed a possibility to integrate into the import library wizard. But it would be a lot of work in an area that very few people really use. The Win32API is powerful but not the complete answer to God, the universe and everything. Also there are areas in Windows you can not really access through that API anymore. In addition I wonder what the motivation at Microsoft is for this, considering their push to go more and more towards UWP, which is an expensive abbreviation for a .Net only Windows kernel API without an underlying Win32 API layer as in the normal desktop version. And at the same time and purely for users safety (of course 😄), also a limitation to only install apps from the Online Windows Store. 😀

But the Win32API is only a very small portion of external code you will typically want to interface to. It does not cover your typical device instrument driver that comes in DLL form, often with the latest update 10 years ago and with the only support in the form of obscure online posts with lots and lots of guesswork and wrong assumptions. Also it won't help with shared libraries from Open Source projects, unless some brave contributor dives into the topic and creates that meta description for it.

But creation of such a meta description for an API is a lot of very specialistic and almost impossible to automate work. Microsoft may really do it, I'm still sceptical if it will be really finished, but most others will probably throw their hands in the air in despair at the first moment they lay eyes on the documentation of this meta description format. 😎 In the best case it will be several years before there is any significant adoption of this by other parties than Microsoft, and only if Microsoft is actively going to lobby for it by other major computer software providers. In reality someone at Microsoft will likely invent some hand brakes in the form of patents, or special signing authorities, that makes adoption of this by other parties extra difficult.

And it won't help a single yota for Linux and Mac platforms, which are also interesting to target with the Call Library Node.

Edited January 23, 2021 by Rolf Kalbermatter

[dadreamer]

I mostly agree with Rolf here. Even though it looks definitely doable, if necessary effort is pushed into, it will require a lot of work for sure, be it Import Shared Library Wizard enhancement or some new tools, based on scripting. At the current stage, I do not even believe that someone will do this in relation to LabVIEW, until it would be done for any other widespread programming languages at least. Besides of that, I suppose, some rework of the current Call Library Function Node is required, as it wasn't really maintained in many years and doesn't allow some use-cases to be automated. For example, many WinAPI functions are able to receive a parameter or NULL instead of that parameter, like MessageBox function:

int MessageBox(
  HWND    hWnd,
  LPCTSTR lpText,
  LPCTSTR lpCaption,
  UINT    uType
);

lpCaption can be a string (that is, String -> C String Pointer in CLFN parameters) or NULL (that is, Numeric -> Unsigned Pointer-sized Integer). That Win32 Metadata framework won't ever know, what we want to pass: a string or NULL value. Thus a CLFN would often require a manual fine-tuning for our needs anyway. There are also some nuances in CLFN on Linux and MacOS platforms, e.g. LabVIEW doesn't produce a drop-down function list in CLFN parameters and does not link to system libraries just by name (like it does on Windows), so a manual pointing is needed. Oh wait, this is about Win32, no Linux/MacOS support is planned at the moment. Also no more SLI wrappers from NXG, please - they are terrible!

Edited January 23, 2021 by dadreamer

[JKSH]

On 1/22/2021 at 10:24 PM, Neil Pate said:

could this in the future be used to simplify configuring Win32 API DLL calls in LabVIEW?

I'm curious: What are some examples of Win32 API calls that have been most useful in LabVIEW programs?

[ShaunR]

40 minutes ago, JKSH said:

I'm curious: What are some examples of Win32 API calls that have been most useful in LabVIEW programs?

I have a whole directory in my toolkit called "Windows Specific" which is for VI's that call the Win32API. But unarguably THE most useful for me is the Win Utils I originally wrote in LabVIEW 5 and still use today. 

Windows API Utils 8.6.zip

[Rolf Kalbermatter]

4 hours ago, JKSH said:

I'm curious: What are some examples of Win32 API calls that have been most useful in LabVIEW programs?

There are various packages around that do different things to different degree. Most of them are actually APIs that existed in the early days of Windows already. Things that come to mind would be querying the current computer name, user name or allowing to actually authenticate with the standard Windows credentials. Others are dealing with disk functionality although the current LabVIEW File Nodes offer many of those functionalities since they were reworked in LabVIEW 8.0. then there are the ubiquitous window APIs that allow to control LabVIEW and other application windows. As far as LabVIEW is concerned most of those things are since a long time also possible through VI server, but the possibility to integrate an external app as child window can be interesting sometimes (although in many cases a questionable design choice).

There are of course many newer Windows APIs too but a lot of them are either to specialistic or to complex to be of much interest to most of the people. For instance there have been many attempts at accessing Bluetooth Low Energy APIs in Windows, but that API is complex, badly documented and riddled with compatibility issues, which would make a literal translation with a LabVIEW VI per API function a very useless idea for almost every LabVIEW user. But once you start to go down the path of creating a more LabVIEW user friendly interface, it is usually easier to develop a wrapper library in C that takes care of all the low level hassles and provides a more concise and clean API to the LabVIEW environment, so that one does not have to do very involved C compiler acrobatic tricks on the LabVIEW diagram to satisfy the sometimes rather complicated memory manager requirements of those APIs.

The problem with the original idea of the metaformat to allow importing Windows APIs is however that the difficulties of using such an API is very often not limited to making it available in LabVIEW through a Call Library Node. That is indeed specialistic work and can require a deep understanding of C compiler details and memory manager techniques, but the really difficult part is to understand how to use those APIs properly and that use also influences often how you should actually import the API as dadreamer pointed out with the example of string or array pointers that can either be passed a NULL value or the actual pointer. It would be almost impossible to provide this functionality in the current Call Library Node implementation, since LabVIEW does not make a difference between an empty string (or array) and a NULL pointer (in fact LabVIEW has to the outside nothing like a NULL pointer since it does not provide pointers). Internally one of the many optimizations is that all LabVIEW functions are happily accepting a NULL handle to mean the same as a valid handle with the length value set to 0. How to tell LabVIEW that an empty string should pass a NULL value in one case and a pointer to an empty string in the other? Some APIs will crash when being passed a NULL pointer, others will do weird things when receiving an empty C string pointer. And that might not even be something that you want to have in the Call Library Node configuration since there exist APIs that understand a NULL pointer to have a very different meaning (such as to use a specific default value for instance) than what an empty C string will do (omitting this parameter for instance). This has to be programmed explicitly anyways by using a case structure for both cases and only a human can make this decision at this point based on the prosa text in the function documentation. A metaformat can say if a pointer is allowed to be a NULL value or not, but being allowed to be NULL doesn't mean automatically that an empty string should be passed as NULL value.

And that all is not really possible to describe in a metaformat in a way that is parsable by an automated tool. It can be described in the prosa text of the Programmer Manual to that function, but often isn't or in a way that says nothing more than what the names of the parameters already suggest anyways. And as mentioned, Windows APIs make only a small fraction of the functions that I have imported through the Call Library Node in my over 25 years of LabVIEW work 

Edited January 25, 2021 by Rolf Kalbermatter

[Neil Pate]

4 hours ago, JKSH said:

I'm curious: What are some examples of Win32 API calls that have been most useful in LabVIEW programs?

I too have a sprinkling of Win32 calls I have wrapped up over the space of many years. Most are pretty simple helper stuff like bringing a window to the front or printing or getting/setting current directory etc. No rocket science here.