My app is a WPF application and it already has code for the older type of System DPI awareness that works well in every version of windows except 8.1. It turns out that Microsoft added a number of functions to Windows 8.1 as part of their implementation of per-monitor DPI awareness. I need to implement code in my program to support this type of DPI awareness.
I have documentation that lists the per-monitor DPI awareness functions and what their parameters are. I need to import those into C# and call them from my window class. But I don't know which DLLs contain those functions! The documentation for the GetProcessDpiAwareness function, for example, does not indicate which DLL it's in.
How do I find what the exports in the DLLs are?
Right out of head, a dumb method: a binary search in C:\Windows\System32 for GetProcessDpiAwareness, then studying each occurrence with Dependency Walker for exports.
This produces the result: GetProcessDpiAwareness is exported by SHCore.dll.
One may also search the Windows SDK headers and libs, but in my case I haven't found GetProcessDpiAwareness, to my surprise.
Another idea, run the following from the command line prompt:
for %f in (%windir%\system32\*.dll) do dumpbin.exe /exports %f >>%temp%\__exports
Then search %temp%\__exports for the API.
I know it's been asked a while back. (Every time I Google it, this question comes up. So let me share my method.)
If anyone wants to search for functions in DLLs, there's this tool that will do it for you. In case of the GetProcessDpiAwareness on my Windows 10 (64-bit) it is exported from shcore.dll like someone had already mentioned above. Here's the screenshot:
Although I need to preface it by saying that it would be always prudent to refer to the function's documentation on MSDN instead. Currently you can find it at the bottom of each page:
If you play around with the search that I showed above, you will notice that many of the system functions are exported from multiple DLLs (some of which are undocumented.) So if you just blindly go with whatever you find in a search app, you may run a risk of breaking your program in the future if Microsoft changes one of those undocumented functions. So use it only for your own research or curiosity.
Usually functions that work with the same resources are in the same dll's. Look at another dpi function like GetDpiForMonitor and you will see it is in Shcore.dll
Edit: After you find the dll this way you can double check using dependency walker to see what functions are exported from that dll.
Related
I would like to build a simple .NET application that installs on a windows machine which will allow the end user to open a command prompt and type "google test" which will open google and search for test. But I'm not sure how to install a global "keyword" such as "google". Is this down via Environment variables? How does this link up to my .NET application?
Any advice or pointers is appreciated.
Thanks
This is beyond a .NET application and belongs into the Area of Setup programms. Visual Studio used to have a Installer Project, but as there are so many 3rd party ways this was removed.
Having "google test" parsed as a google search for "test" is tricky, but possible. However it depends entirely on how the commandline is parsed in a Windows. Wich is pretty much the way it was parsed since DOS 1.0.
If you just enter a word like "google", the commandline will look if there is a Excetuable file (.exe, .com, .bat) of that name in the current folder (working directory). It will then look into all the folders defined in the path variables. However using path variables is so dated, I could find only a single entry in my Windows Path variable now. And it is for MS backward compatibility: "%USERPROFILE%\AppData\Local\Microsoft\WindowsApps;"
Most starting of programms is done via file associations with a specific type. And protocoll associations with a protocoll (like http, https, steam). Indeed my advise would be to make a .NET Programm named "google" whose sole purpose is to to format the proper URL, then send it to console parsing via ProcessStart. And let Windows solve wich programm to use from there.
Edit: And as I only realized after wirting this, apparently Windwos finally supports commandline aliases. https://learn.microsoft.com/en-us/windows/console/console-aliases
Apparently they even added a way to make them via the WinAPI in Windows 2000. However that requires moving to unmanaged code. And I have no experience, but it appears those aliases might only be valid for one console instance. So you might have to put it into a place like hte autoexec.bat to be called everytime a console is created.
I'm currently using C# and Win32 interop to register power setting notifications, enumerate power setting guids, etc. In the process of this, I came across a function in the MSDN documentation called "PowerIsSettingRangeDefined" that looked useful. When I imported the function and tried to test it, the compiler threw "System.EntryPointNotFound" exception. Obviously I double checked my spelling, etc, to no avail. So I looked for the header file on my computer and I did find the function listed in the 'powrprof.h' header for the 8.0 SDK, however, I don't have a copy of the 7.0 or 7.0A SDK on this computer. But according to the documentation, this was supposed to have been implemented starting with Windows 7. So this should have worked...
Then I used ProcessHacker to inspect the export table of the 'powrprof.dll' module in my process. The function was NOT there! To take it one step further, I used PE Explorer on the actual 'powrprof.dll' file located in "C:\Windows\SysWOW64\" and the entry point in question, again, was NOT in the name list. So the official header files include this function with "#if (NTDDI_VERSION >= NTDDI_WIN7)" above, and the documentation shows the function exists starting with Win7, however, it seems the MS team did not include it when compiling 'powrprof.dll' for Windows 7.
Maybe someone can check their copy in Windows 8.1/10 to see if this issue is only on Windows 7? I don't have another version of Windows in this building or I'd test it myself. And I wanted to bring it to attention here first, before trying to report this to Microsoft, just in case I'm missing something.
I work for an IT company where we all carry around flash drives that have our most used programs on them.In my spare time I am hoping to create a "main menu" item that is kind of a fun and convenient way to access these files. I am working on creating this using Visual Studio 2013 and using visual C# windows forms. I have come across a snag however that I can't seem to find a workaround for. I am by no means fluent in C#, but I need to have a button on the windows form open a file without specifying what drive it comes from. I understand that I have to specify a path, but as these will be stored on the flash drives of myself and my coworkers I cannot foresee that the path will always begin with E:. Depending on what USB slot the drive is plugged into it could be N: or F: or the like. I have provided an example below:
Using what I currently know I am opening files using this line of code:
System.Diagnostics.Process.Start("C:/Users/Myname/Desktop/Asmodeus/Anti-Virus/Anti-Virus Installers/avast_free_antivirus_setup.exe");
Is there any way possible I can have the file open simply from
System.Diagnostics.Process.Start("Asmodeus/Anti-Virus/Anti-Virus Installers/avast_free_antivirus_setup.exe");
or something of that nature?
Thanks in advance.
There must have been some mis-communication when I asked my question previously. what I am looking to do is open an executable file via a button click on the windows form using a relative path. I am not able to specify the absolute path because the application will be run from a flash drive and therefore will change depending on what USB slot it is currently inserted into.
What I am hoping to accomplish is insert a line of code that will allow me to open an executable file that is located in the \bin\debug folder along with the application itself. I have a picture for clarification but apparently do not have enough reputation to post it. Thank you and sorry for the earlier confusion.
Usually you can just use Environment.GetFolderPath (MSDN) to give you what you need. It doesn't do absolutely everything, but if you need Desktop and the like, that is plenty.
Depending on the target version of .Net, the SpecialFolders exposed are not all there. It may turn out that you need more than they provide, but in your case it doesn't sound like it.
If there is more you need that is not covered in the default, check out this project. I'm sure there are others like it, but it does a little more than the default BCL version, using the API directly. It is at least something to read and learn (and translate from vb.. use an online translator, very quick). I haven't looked at it, but it seems like you are learning this c#/.net thingy, so it might be helpful
This article is about accessing Windows special folders.
These folders include your “Favorites”, “Cookies”, system libraries and the like.
Here is code, including a large number of constant definitions, plus documentation,
allowing access to and creation of these folders.
The new version of Ghostscript (9.07) has a threading support (can be thread-safe), but it says that the code must be compiled with a special flag to enable this.
How do I do this? Or where can I get already built thread-safe version?
I tried to download the source, opened in VS, but it failed to build. So maybe somebody has already done this and could share the DLL.
Are you interested in the thread safe version of Ghostscript, or multiple rendering threads?
Multiple rendering threads are only of use if you are producing high resolution output, since the code must first interpret the PostScript program (or PDF file) and create a display list for the rendering threads to operate on. Unless you are rendering to a reasonably high resolution, this will actually be slower than using page mode (whole page rendered in memory)
You can create multiple rendering threads in the pre-built version of Ghostscript using the -dNumRenderingThreads switch.
If you want a thread-safe version of Ghostscript then you will need to be able to compile Ghostscript yourself. What version of Visual Studio are you using ? I am using Visual Studio 2005 and 2008 and the supplied solution works for me (after appropriate conversion).
I was looking for solution for this problem as well and eventually I solved it in Linux. Maybe it will help someone who comes here looking for solution.
Open terminal in sources directory and type this command:
./configure --enable-threadsafe
After that you can do make or make so for lib.
Here is link to docs for building ghostscript from sources: https://www.ghostscript.com/doc/9.23/Make.htm#Makefile_overview.
Take a look at Ghostscript.NET managed Ghostscript wrapper which allows you to run multiple instances of Ghostscript library at a same time if you have a need to process multiple pdf's at a same time.
for extracting special folder icons I'm using
ExtractIconEx(Environment.SystemDirectory + "\\shell32.dll",ncIconIndex, handlesIconLarge, handlesIconSmall, 1);
Here im passing explicitly nIconIndex for special folders like MyDocs,MyPictures ..etc
and its working fine in XP ,however in Vista its not retrieving the correct icons ..there it retrieves yellow folder icons..it should not be the case.
Cn anybody help me on this..
Vista added a new API called SHGetStockIconInfo but it does not support my documents AFAIK. But that does not matter since the method you SHOULD be using works on both XP and Vista (Your current solution will not work when the user has selected a custom icon, you are just looking in hardcoded system dlls, this could change at any point)
So, what you should do is, get the path or PIDL to the shell folder you are interested in (SHGetFolderPath and friends) and pass that path/PIDL to SHGetFileInfo. SHGetFileInfo can give you a icon handle, or the index into the system image list.
I'm not sure what the .NET equivalent for those functions are, but you should be able to figure that out, or use PInvoke
Check out the IconLib library at codeproject.
The best example I've seen of success in this area from .NET (and it was done with VB.NET) is in this article.
http://www.codeproject.com/KB/cpp/VbNetExpTree.aspx
My $.02 is that working with the shell API is extremely painful from .NET due to the level of COM interop required and the complexity of the API's.