The documentation of CreateDIBSection states:
If the function succeeds, the return value is a handle to the newly
created DIB, and *ppvBits points to the bitmap bit values.
If the function fails, the return value is NULL, and *ppvBits is NULL.
However, directly after that it states:
This function can return the following value [...] ERROR_INVALID_PARAMETER
So, what is meant by this last sentence? I can hardly imagine that it really returns that value (possibly it actually calls SetLastError). Is this somewhere thoroughly documented?
This is simply an error in the current version of the documentation!
The CreateDIBSection always returns an HBITMAP. If the function fails, then it will return 0 (NULL), and you can call GetLastError. GetLastError will return ERROR_INVALID_PARAMETER.
This is the standard way that all GDI functions work, not to mention the fact that it is impossible for a function return both NULL and an error code. I was also able to dig up an old version of the MSDN documentation for this function (circa 2008), and it confirms that the current version of the online documentation is indeed erroneous:
Related
CopyFileEx with a following call to GetLastError returns ERROR_INVALID_PARAMETER even if the copy is successful on Win2012R2 since around 2 months back (maybe from December 2015). On Windows XP till Windows 7 and Win 2k3 till Win2k8R2 this does not happen and GetLastError always returns 0 (ERROR_SUCCESS).
Is this expected behavior of this kind of Win32 API?
Do you have to add both result and GetLastError code be sure of the result?
This KB seems related to the problem but applying this patch does not alter the API behavior. There was probably another KB that caused the problem to appear but I have been unable to find it
https://support.microsoft.com/en-us/kb/2963918
Documentation for GetLastError:
Return value
The return value is the calling thread's last-error code.
The Return Value section of the documentation for each function that
sets the last-error code notes the conditions under which the function
sets the last-error code. Most functions that set the thread's
last-error code set it when they fail. However, some functions also
set the last-error code when they succeed. If the function is not
documented to set the last-error code, the value returned by this
function is simply the most recent last-error code to have been set;
some functions set the last-error code to 0 on success and others do
not.
From the documentation:
Return value
If the function succeeds, the return value is nonzero.
If the function fails, the return value is zero. To get extended error
information call GetLastError.
In other words, if the function succeeds, you are not expected to call GetLastError, and no promise is made about what will be returned if you do.
So, you are ascribing meaning to the value returned by GetLastError where no meaning should be ascribed.
This is a common pattern in Win32. A great many functions are similar. The value returned by GetLastError is only meaningful in the event that the return value of the function indicates failure. That is not a universal rule though, so you do need to check the documentation on a function by function basis.
The typical form of a call to such a Win32 function looks like this:
if (CopyFileEx(...))
{
// function call succeeded, continue
}
else
{
DWORD err = GetLastError();
// do something with err
}
Note that GetLastError is only called if the function indicates failure through its return value.
I am using a 3rd party library that invokes a Core Foundation function.
Since that lib has a bug, passing incorrect values to a CF function, I need to intercept that call to fix the passed values.
How do I hook into the CF function call so that I can look at the passed parameters, change them and then call the actual (original) function?
I have the impression I can get to the actual function with the CFBundleGetFunctionPointerForName, passing CFBundleGetMainBundle()as the first parameter and the name of the CF function as the second parameter.
In my particular case, that would be:
void *p = CFBundleGetFunctionPointerForName (CFBundleGetMainBundle(), "CFRunLoopTimerCreate");
But that returns NULL.
I also tried this:
void *p = CFBundleGetFunctionPointerForName (CFBundleGetBundleWithIdentifier("com.apple.Cocoa"), "CFRunLoopTimerCreate");
That returns a non-null value but it still does not appear to be a pointer I could change but rather the actual starting address of the function's code.
So, how do I get an address of a function pointer to an imported API function that I can save and then change to point to my intercepting function? Or how else could I hook into an imported function?
CFBundleGetFunctionPointerForName will just return the address of a function in a given bundle; this will never let you change the destination of calls to the function. If you really want to do something like that, please refer to Is it possible to hook API calls on Mac OS? Note that this is highly not recommended.
After doing promisify on a specific function with bluebird - is it possible to get a reference to the original function that was promisified?
Why: I'm using a helper that gets argument names from the function and on promisified functions it gives back (_arg0, _arg1, _arg2), I was hoping it was possible to get the original function signature from somewhere.
No, you can work around it though.
If it is promisified with promisifyAll you can access it without the Async suffix - otherwise, you'd have to do it yourself:
var promisified = Promise.promisify(cbFunction);
promisified.original = cbFunction;
// access as promisified.cbFunction from that point on.
Otherwise, the original function is captured via a closure and you can't reliably access it. In all honesty you probably shouldn't since that'd meddle with minification anyway.
I am failing to create a file in windows using the CreateFile API, GetLastError returns the error code 80 which means the file exists, but actually the file was not existing.
hFile = CreateFile((LPCTSTR) FILEPATH, // name of the write
GENERIC_READ|GENERIC_WRITE, // open for writing
0, // do not share
NULL, // default security
CREATE_ALWAYS, // create new file only
FILE_ATTRIBUTE_NORMAL, // normal file
NULL); // no attr. template
printf("GET LAST ERROR VALUE IS: %d\n", GetLastError());
What am I doing wrong?
Your error checking is wrong. The documentation says:
Return value
If the function succeeds, the return value is an open handle to the specified file, device, named pipe, or mail slot.
If the function fails, the return value is INVALID_HANDLE_VALUE. To get extended error information, call GetLastError.
In other words, failure is determined by the return value. You cannot use GetLastError to determine failure. You must check the return value and compare against INVALID_HANDLE_VALUE. When you do so I predict that you will find that the return value is not equal to INVALID_HANDLE_VALUE.
In fact, this API uses the last error value to convey extra information even when the function succeeds.
From the documentation of CREATE_ALWAYS:
If the specified file exists and is writable, the function overwrites the file, the function succeeds, and last-error code is set to ERROR_ALREADY_EXISTS (183).
And from the documentation of CREATE_NEW:
Creates a new file, only if it does not already exist.
If the specified file exists, the function fails and the last-error code is set to ERROR_FILE_EXISTS (80).
And so on.
The golden rule, one that you must burn into your memory, is that error checking varies from function to function and that you must read the documentation from top to tail.
Note that I am rather sceptical of your (LPCTSTR) cast. That's just asking for trouble. If the path is the wrong type, the compiler will save you from yourself, unless you use that cast. That cast just tells the compiler to shut up. But here it knows better. That cast will allow you to pass ANSI text to a wide API and vice versa. You really should remove it.
GetLastError can cause trouble.
Note the docs say
"If the function fails, the return value is INVALID_HANDLE_VALUE. To
get extended error information, call GetLastError."
So, first, only call GetLastError if you get and INVALID_HANDLE_VALUE handle back from CreateFile.
Second, the last error code can be the , well, liertally, last error code - i.e. the most recent call may be OK, but something previously failed: again from the docs
"If the function is not documented to set the last-error code, the value returned by
this function is simply the most recent last-error
code to have been set; some functions set the last-error code to 0 on
success and others do not."
I am confused about the ref count in npapi. Mostly, I don't know which method will increase ref count. Can anyone explain in detail about this? For the convenience, I listed most common used NPN_* functions here and my own understanding:
NPN_CreateObject: set ref count to 0
NPN_RetainObject: inc ref count
NPN_ReleaseObject: dec ref count
NPN_Evaluate: ?? (in case return an NPObject*)
NPN_GetValue: ?? (in case return an NPObject*)
NPN_SetValue: ?? (in case set to an NPObject*)
NPN_GetProperty: ?? (in case return an NPObject*)
NPN_SetProperty: ?? (in case set to an NPObject*)
NPN_RemoveProperty: ??
NPN_Enumerate: ??
NPN_Construct: ??
another thing: is npapi do nested release? (In case NPObject* with a property of NPObject*, release parent will decrease the ref count of child).
Thanks.
There isn't room in comments to answer your question in the comment well, so I'll put it in another answer.
Any time your code gets an NPObject from a NPObject function (one of those you mentioned above), you should Release that NPObject when you're done with it. (that could be immediately, or you could save it for awhile and release it when your object gets destroyed). The same holds true with a NPVariant. It does not hold true with the arguments passed into your Invoke function, but the return value you set will get released by the browser when it's done.
When you call NPN_GetValue and get an NPObject from there, that also has to be released. This means that when the browser calls NPP_GetValue, it will release your NPObject when it's done. If you want to create a new NPObject every time the browser calls NPP_GetValue to get your NPObject, then you don't have to call NPN_RetainObject on it; the assumption in the NPAPI example is that you are saving a copy of your NPObject so that it doesn't get deleted until your plugin object gets deleted.
Since the browser will call Release for every time that it calls NPP_GetValue to get your NPObject, you need to make sure that the refcount is incremented before you return it. The reason you don't have to call it twice in the case that you're going to keep it is that NPN_CreateObject does an implicit Retain before it returns your object.
I have written up a more detailed explanation here:
http://colonelpanic.net/2009/12/memory-management-in-npapi
First, to correct a misconception: NPN_CreateObject sets the refCount to 1, not to 0. Then, when you call NPN_RetainObject it increments the refcount, and NPN_ReleaseObject will decrement it. If ReleaseObject decrements the refcount to 0, it will also free it by calling the deallocate function from your NPClass (which should delete the NPObject after doing any needed cleanup)
see: https://developer.mozilla.org/En/NPClass
beyond that, a good general rule of thumb for any of the other NPClass functions is that any time you put an NPObject in a NPVariant, you need to call NPN_RetainObject. To remember this, simply remember that when you're done with an NPVariant (one that you have used and are done with, not one that was passed as a return value), you call NPN_ReleaseVariantValue, which will release the NPString data if it's a string or the NPObject if it's an object.
So from any of the other methods, if you are returning an NPObject, you need to call NPN_RetainObject before you stuff it into the NPVariant. Also, if you save a copy of the NPObject, you should call NPN_RetainObject on it and NPN_ReleaseObject when you're done saving it. It also bears mentioning that you should never call any NPN_ method from a thread other than the main thread.
Does that help?