Why use Buffers instead of plain integers for handles?

I notice that the user32 functions in this library, such as FindWindowExW return Buffers as the window handles.

However, I’ve seen other implementation of these functions in ffi just use simple integers – for example, at bottom of this answer: https://stackoverflow.com/a/40733935/2441655

Question 1: Since simple integers are easier to log and pass around in Javascript, why does this library use Buffers instead?

There must be some advantage to it, but I’d like to know what it is so I can weigh whether to keep using this library or make a variant that just uses simple integers/js-numbers as handles.

==========

Oh also, how do you create a new “Buffer handle” if you have a handle in integer/js-number form?

I assumed one could just do:

var handle = [function that gets window handle, as simple integer/js-number].
var handleBuffer = Buffer.alloc(4)
handleBuffer.writeInt32LE(handle, 0);

However, whenever I pass that handleBuffer object to the ffi functions, it ignores them/acts like they’re invalid. So I must be creating them wrong.

Question 2: Is there a straight-forward way of creating handle-buffers based on an integer-handle?

[Venryx]

pls try next version win32-api@^9.0.0 type HANDLE changed to number | bigint | string (uint64/uint32)

Great! Thanks for your work on this issue, despite my limited description/grasp of it.

When I have time to try out the new version, I’ll plug it into my project (removing my old modifications), and let you know if it works as expected.

Should we use this ? […]

I prefer the first, the param handle/hmodule etc, somewhere is input param( as number), somewhere is output param(as buffer/pointer).

I looked the file and description over for a bit, but to be honest, I am not really sure what the difference between the two approaches are. Partly it’s a language barrier, but mostly it’s just that my familiarity with pointers/buffers/etc for the Windows API is low, so I don’t know, for example, how M.HMODULE differs from a Buffer or pointer.

I understand the basic concept of a pointer (theoretically, and practically to some extent, as I had to in the past to get some Windows API calls to work using ffi), and also understand some of how Buffer works (it’s a special “shapeless” Javascript construct which is linked to a stable point in unmanaged memory, with ffi providing functions to read and write to that unmanaged memory), but I haven’t worked with them enough to easily grasp what the specific code elements Buffer, "pointer", and M.HMODULE specifically represent in this context.

In summary: I don’t understand the difference between the two, so just do what you think is best for now. 😆

[Venryx]

I haven’t used the COLORREF or LPCOLORREF structs in any of my projects, so I can’t answer for those specific cases. However, I do know that wherever window handles were involved, using number instead of Buffer worked fine.

My guess is that a simple number type would work for those other structs as well, since node-ffi apparently translates values to the correct types (ie. a pointer) internally. (assuming the js-type can fit the data, of course)

Of course, there are still cases where you’ll need Buffer, for example when you call an API function that merely modifies an object referenced-by-Buffer; but those are the exception rather than the rule, and for the simpler pass-object or receive-object-as-return-value cases, replacing Buffer with number has worked for the instances I’ve tried.

So basically, I would suggest either:

1. “incrementally” changing Buffer usages to number, as tested by people using the function and confirmed working. (eg. I’ve tested a number of calls that use window-handles, and they all work fine with number params and return-types)
2. Try out a few other cases of Buffer converted to number, and if all of them seem to work, assume they all do (of the direct-transfer type), and convert them all at once.

Sorry I can’t be of more help! Just passing on what I’ve noticed in my time using node-ffi for win-api calls.