I agree LoadBitmap should not fail like that but it is specified the resources are never lifted into RAM. They are tagged in special sections in the file and are excluded from the normal executable load to avoid using memory when not required. Remember a file may contain many resources for different resolutions, languages and the like and much would then be redundant duplicates hogging memory.
Thank you Richard. I reread the remarks and I see that you are correct.
However, because a 32-bit application must run the hook code, the system executes the hook in the hooking app's context; specifically, on the thread that called SetWindowsHookEx. This means that the hooking application must continue to pump messages or it might block the normal functioning of the 64-bit processes.
When I install the hook, I must pass a pointer to the hook callback function. However, that's a pointer that's only valid inside the process space of the application installing the hook. How does it use that pointer to call the correct code inside the address space of the application that is a target of the hook?
The difficult we do right away...
...the impossible takes slightly longer.
The system keeps that address (which is the target of the hook) and uses it to call back into your application at the appropriate time (i.e when the relevant hook event triggers). But if you close your application, its address space is destroyed and the hook is no longer valid, so the system will no longer call it.
Sorry I don't know the answer to that one. There is an implication that injecting the hook into another process can be done of the call-back function is in a dll. If that is the case then the dll must be associated withe the address space of that process. I must admit it is a long time since I used this feature so my recollection of it is not 100%.
Why I am asking that ? Even if _open return 3, further more, the reading of boot section has failed.
say that my boot device is not NTFS:
if (! ntfs_boot_sector_is_ntfs(bs))
errno = EINVAL;
BOOL ntfs_boot_sector_is_ntfs(NTFS_BOOT_SECTOR* b)
BOOL ret = FALSE;
ntfs_log_debug("Beginning bootsector check.\n");
ntfs_log_debug("Checking OEMid, NTFS signature.\n");
if (b->oem_id != const_cpu_to_le64(0x202020205346544eULL)) // "NTFS "
ntfs_log_error("NTFS signature is missing.\n"); // <--- my code run by here
Of course, this debugging session ran as admin mode.
I haven't gotten around to check this out myself yet, but I am studying the "Windows Internals" book by Mark Russinovich (the guy creating the Sysinternals suite). There I found that the object name \Device\HarddiskX\DRX (with 'X' being replaced by a digit from 0 upwards; you can find it using the Sysinternals WinObj utility).
It is not clear to me when to use this name and when to use the \Global??\PhysicalDriveX name. Russinovich writes that "The Windows application layer converts the name to \Global??\PhysicalDriveX berofe handling the name to the Windwows object manager" - it seems like that PhysicalDriveX format is some old legacy format. It is far from clear to me!
So you may try a Global??\ prefix, or you might try \Device\HarddiskX\DRX (appearently with X replaced by 2 in your case). When you find out what works, tell it, and I will use it when I get that far myself!
I was not pointing out the name to be used -- I was pointing out the access that must be used. Since your disk name is correct (assuming that drive 2 exists ), the access mode seems like a good subject for investigation. A quick google indicates this is OS-dependent when using the open function.
Be wary of strong drink. It can make you shoot at tax collectors - and miss. Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
Last Visit: 18-Sep-20 21:19 Last Update: 18-Sep-20 21:19