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.
Related
I have a Win7 PC in use as part of an experiment control system. The experiment in question uses 4 windows simultaneously, and I would like to find away to open, position and size these 4 windows with a script.
The script would run at start up, so that the newly booted PC presents the user with the four windows as default.
Obviously I can use a batch file in the startup folder to open windows and run applications, but is there a way to specify the layout of these windows?
Many thanks
Si
Assuming that you have access to a scripting language that supports making calls to Windows API functions it shouldn't be too hard. Otherwise I'd suggest writing a small executable in some language (at least any of C++, C# or VB.Net would all work fine) and have that do it.
You could use FindWindow, as described here, to find the windows and MoveWindow, as described here, to move them around.
I use an AutoHotkey script to set up all my environment (around 7 windows in 3 different virtual screens), works pretty well. You can set the location of windows etc.
I can use a batch file to open the apps, then run WiLMA to relocate them
I have been looking into the possibility of creating a soft copy(image/EMF file) of everything printed from Windows - for archival purposes. Does anyone know if it is possible to create a hooking DLL that can grab the printed data in such a general way?
A low tech way of solving it might be to install pdf printer driver as the default printer and remove all others and set it up to automatically write all the files to certain directory on the network and then write a tiny app on another computer to monitor that folder for changes and if any new pdfs appear just print them out to a real printer.
Edit: Otherwise there's apparently something called the Print Monitor API. Here's an article that describes using that from VC++ 6 and seems to be pretty much what you want (assuming it's still supported by the OS you use).
Having looked at this problem in more detail the best solution seems to handle it through Spooler notifications in the Win32.
I am starting to design a DMO to run from inside a windows media player activeX control in Internet Explorer.
is there any reason why using windows named pipes from inside the DMO wouldn't work?
user permissions/privilages/ kernel mode stuff?
Thanks :)
Roey
I have not tried it but I can't think of any particular reason it could not work. However, keep in mind that starting with Vista Internet Explorer runs as a low integrity level processes so any pipe you connect to will need to have it's access control set accordingly.
I have done this from a FireBreath plugin (activex control on IE, npapi on others) and the only thing you need to keep in mind is that activex controls in IE are often running in low integrity mode, so you need to make sure you set the ACL mask on the pipe correctly. As long as you have it configured correctly, it works fine.
Windows XP Embedded is missing the NULL or "NUL" device. For one thing, Visual Studio seems to require it and trying to build a project aborts with a PRJ0015 error.
Anyone know how to configure an XPe image to include support for the NUL device?
"Null Device Driver" is available in the XPe Target Designer, but it's normally hidden. Apparently each component has a visibility level, and if it's lower than that set in the Target Designer options (Tools->Options), it's hidden. Null Device Driver is at level 200, so I set the level to 100 and could see it and install it.
There's another important situation where you're going to want the NUL device: if you're installing some or all of the Cygwin UNIX solutions for Windows. In particular, if you're doing something like, oh, I don't know, to pick a completely random example, trying to put an SSH server on the damned thing so you can, just on a lark, say, log in and maintain it.
That's right-- Cygwin actually maps its UNIX /dev/null device to the Windows NUL device. You know, for maximum compatibility. Just in case the platform-specific implementation of IMMEDIATELY THROWING DATA INTO THE TOILET AND OBLITERATING IT, NEVER TO BE SEEN AGAIN, UNTIL THE HEAT DEATH OF THE UNIVERSE, happened to be novel and innovative.
While cygwin will INSTALL without NUL available, it will not, in fact, actually enjoy a typical work day. This is most evident the first time you try to launch a bash shell, and notice a slew of error messages about /dev/null resulting in no such file or directory errors. One presumes the device is perhaps actually just an NTFS link, but who knows.
In any case, the fix is to add the "Null Device Driver" component, helpfully located under Software -> System -> Other, a surprisingly small category which also contains such useful components as Internet Checkers, the Schedule Service Command Line Utility, the 1394 Kernel Debugger Support Library, EBCDIC support for Microsoft Bob, some cheat codes for Zork, and the code pages to say "(A)bort, (R)etry, (I)gnore, (F)ail?" in Muppet Swedish ("(B)ork, b(o)rk, bo(r)k, bor(k)?")
Hope this helps,
Matt "Breakpoint" Heck
Running Visual Studio itself on XP Embedded doesn't seem like it'd be supported. You should build on a full OS and then just deploy your application to XP embedded.
It's possible, but is it appropriate to use SHFileOperation within a Windows service? All those SHxxx API functions in shell32.dll seem to have been written with user level programs in mind. Can I be certain SHFileOperation won't display GUI ever?
According to the SHFILEOPTSTRUCT documentation, you can use the following flags to prevent any UI from appearing:
FOF_SILENT | FOF_NOCONFIRMATION | FOF_NOERRORUI | FOF_NOCONFIRMMKDIR
or (if you're targeting Windows Vista), FOF_NO_UI, which is the same as the above.
Looking in the ShellAPI.h header file in the Windows SDK, the comment against FOF_NO_UI says "don't display any UI at all", so from this I assume it's OK to use SHFileOperation.
I would say, not it's not appropriate or advisable. Most of the shell32 APIs were written with a basic understanding that they would be used in interactive processes. I don't think there is any way you can guarantee that SHFileOperation will never display a UI component. In fact, if you look at IFileOperation (which is the new Vista interface that replaces SHFileOperation), it clearly states:
Exposes methods to copy, move, rename, create, and delete Shell items as well as methods to provide progress and error dialogs. This interface replaces the SHFileOperation function.
I have to agree: not appropriate or advisable.
The prinicpal reason to use SHFileOperation is to perform operations with a UI, and/or which are reversable. I.e. using SHFileOperation to delete files is going to place the files in a recycle bin rather than deleting them allowing the current interactive user to undelete, or undo the operation performed.
As the services run on a non interactive desktop, no one will ever be able to clear that recycle bin out.
I had this issue as well and working at implementing a secure and reliable network file copy between servers and network shares ( most of these shares are CIFS / NetApp filer based ) and SHFileOperation fails from time to time.
now started using ROBOCOPY (available by default in all Microsoft OS from Vista/Server 2008 upwards) and really looks interesting and reliable.
this has opened my eyes: https://stackoverflow.com/a/1030752/559144