Does anyone have an idea in what modules I can find the standard windows cursors?
or does anyone have an idea how to save a cursur (HCURSOR) to a file (*.cur)
User32.dll contain a number of system cursors and other resources
Related
When my plugin DLL is loaded into the host application's address space, I need to write some data into a file. The problem is that at that point of time this file is already opened by the host process with exclusive write access, and my call to CreateFile fails with ERROR_SHARING_VIOLATION
I wonder, can I somehow obtain the file handle from the host process using WinAPI calls? This looks like a terrible idea, but I really need to write into that file. Does someone have any good ideas about how to resolve this problem?
Open handles can be enumerated via NtQueryInformationProcess and/or NtQuerySystemInformation, but it isn't officially supported (you can find non-Microsoft documentation readily with Google) and may not work in future versions of Windows.
I have some files that use alternate data stream and are not shown on windows explorer. I would like to make a shell extension or a program that runs on background that when I use windows explorer and navigates to a folders that has alternate data streams files, to show this file to windows explorer but with an overlay icon on it.
Is this possible? Is there a sample code to check?
Thanks a lot.
Another, more recent, option, that works with Windows Explorer x64, too, is AlternateStreamExtension. It also provides icon overlays.
You can find it here.
There's already a shell property sheet handler available from Microsoft called StrmExt. Granted, it's not quite what you're looking for, was written for Windows 2000 and Windows XP, and has to be recompiled for 64 bit versions of Explorer, but it includes the C++ source code, which should give you a place to start, at least.
In Windows Vista, two new API functions were introduced to allow easier enumeration of Alternate Data Streams: FindFirstStreamW and FindNextStreamW. These functions work much like the other FindFirstX and FindNextX type functions that have been in Win32 for years.
Linux operating system identifies files by looking at its magic number at the starting of the header. How does windows do it ? Does it also have some kind of magic number mechanism or does it only rely on the file extension ?
It relies only on the extension, as provided by the filesystem; the contents of the file are not examined. See e.g. this article - it talks about Windows XP, but AFAIK the general behavior is shared by all released versions of Windows so far: http://support.microsoft.com/kb/307859
On Windows 7, starting a program located in an Alternate Data Stream (e.g. start c:\temp\application.exe:hiddenProgram.exe) does not work anymore!
Using Process Monitor, I see that the access result is OK, but somehow, the OS is blocking access to this file. On Vista and earlier versions, this method used to work.
Does anyone knows how to start it using windows 7 ?
Do what Marc Russinovich does with the Sysinternals tools: store additional executables as resources in the main EXE and unpack them when needed.
There is an additional advantage over ADS: portability. ADS do not survive being stored on FAT formatted volumes, for example.
This technique can indeed be helpful if you want to distribute single EXEs that unpack required device drivers or other helper tools when needed (-> Sysinternals).
I just stumbled on this article on MSDN that says a path can be 259 characters + NUL termination, but if you prefix it with "\\?\" WinAPI allows you to use the
maximum total path length of 32,767 characters.
Eager to see it working I tried using that prefix from Explorer (On XP SP3) but it doesn't work at all (on any path). If you put \\?\C:\Path\to\an\existing.file on explorer's bar, it will give the "file not found" error.
So I'm confused. Can I code something for (non-ancient) Windows that makes full use of the mentioned path size on NTFS? Why Explorer doesn't use it?
There is a SET of API calls that are work with extened-paths and some that do not. The MSDN usually mentions this.
Not that if you just type that path into windows explorerunder xp this does not work, because the extened path syntax is just an escape sequence for the WIn32 API and not for windows explorer. Now, In Win7 this does work because many people expected this to work.
Also for long paths, it does help if you change the working directory or open up explorer with a sub-directory as a root.
Before someone tells me to RTFM...
Note that these examples are intended for use with the Windows API functions and do not all necessarily work with Windows shell applications such as Windows Explorer.
[...]
For file I/O, the "\\?\" prefix to a path string tells the Windows APIs to disable all string parsing and to send the string that follows it straight to the file system. For example, if the file system supports large paths and file names, you can exceed the MAX_PATH limits that are otherwise enforced by the Windows APIs.
On a secondary note, this makes me wonder about the possibilities of hiding files (or finding such files) from explorer by using illegal file names.
Are you asking why all components in Windows do not support it, or are you asking whether it's legal to use these long paths?
You can definitely safely use them, but you may irritate someone who wants to use tools like Explorer to browse them. We see paths like this all the time in the wild. Sometimes people are pretty surprised when they can't use MY_FAVORITE_TOOL to delete it...