Let me start by saying that I don't know what I don't know at this point, so rather than specific answers, I'm also looking for better questions to ask, I think. My .Net/C# is solid enough, and my C/C++ is meh.
Lately, I'm finding that there are no libraries in the standard .Net framework to accomplish certain tasks, and while it's easy enough to download a third party library, I'd like to understand how to do it myself if one doesn't already exist.
In one recent case, I need to deal with MIDI in windows at a relatively low-level, and I accidentally found out that "winmm.dll" is the library I'll need to use by downloading a .net wrapper for MIDI and browsing through the source. I understand that I'll have to make a wrapper class and do the whole P/Invoke thing to make that happen.
The next thing I did was to search for documentation on the Windows API to figure out what was going on in the mystery box of "winmm.dll," and to my delight, there was a whole Windows SDK that I was able to download and read through. I went through the "getting started" section of "Windows Development" which covered some of the basics via C++. It talked a bit about COM, windows header files, and I know enough C++ to get the gist.
Now, I need help connecting the dots on a few issues:
1) The Windows SDK, so far, seems to suggest that I want to program to specific header files rather than the dlls themselves, but the .net wrappers I've found typically point to a specific .dll rather that a header file...
/// <summary>
/// Returns the number of MIDI input devices on this system.
/// </summary>
/// Win32 docs: http://msdn.microsoft.com/en-us/library/ms711608(VS.85).aspx
[DllImport("winmm.dll", SetLastError = true)]
public static extern UInt32 midiInGetNumDevs();
I was under the impression that a header file and DLL needed to be in the same folder, but the windows SDK includes a folder with all the windows header files, and no DLLs (I'm guessing the registry comes into play here for mapping to specific libraries?)? How do those header files eventually get mapped to actual libraries, and why does it seem like I don't even need to deal with header files to create a .Net wrapper?
2) I can't seem to find documentation on winmm.dll, but I have found references to the functions I'll likely need in the "Windows API" list in the Windows SDK, and I'm pretty sure that the code for those functions are in winmm.dll. How do I find the documentation for the specific libraries I'll need to begin creating my wrapper? If I didn't know that I was going to need winmm.dll to access windows MIDI functionality, how could I have figured that out myself?
3) Some DLLs are COM, some are plain windows DLLs, some are .net DLLs... how can I tell the different going forward? It seems that creating wrappers for the former two would require a different approach.
4) There is no page on MSDN for "Winmm.dll" listing all of its API, and I assume there's a good and practical reason for that, but I'm not sure what it is? I'm used to .Net land where I can figure out what a library does and how to use it almost without effort.
Thanks in advance for any insights.
The bible on this is Adam Nathans excellent book '.Net and COM the complete interoperability guide'
Includes PInvoke and several audio-type examples
1) The windows API documentation includes the header, library, and dll file for each method/enum/etc. I just didn't scroll down far enough when I read through to notice this. A header file doesn't necessarily have to be in the same directory as the dll; its contents are simply copy/pasted into the .c file when the program is compiled. The part I was missing here was the linking stage of compilation which I read about here
2) The documentation was there--I just had to look for it a little bit harder.
3) How can I detect the type of a dll? (COM, .NET, WIN32)
4) The api for audio could theoretically span multiple dlls, so the best course of action is to find the API documentation, find the methods you want to wrap, then figure out what dlls those methods are in, and then import each of those DLLs.
Related
I'm currently working on a project which requires me to extract data from GUI on Windows OS - say I need to extract content such as the URL in my browser or the name of the attachment on Gmail.
I have already tried LDTP/Cobra, however it's pretty slow - each request can take up to 5 seconds and I need this library to be reasonably fast. Besides that, the LDTP/Cobra is pretty outdated and the latest MSI file doesn't work with python 3.* unless you modify the library itself.
I've been also researching the pywin API, however, it seems that you can't really extract anything with FindWindowEx and WM_GETTEXT method anymore, but I might be wrong.
My question is - is there any other library that would allow me to extract basically anything from a given Window? Maybe I'm missing an important part of the mentioned libraries? Ideally, I'm looking for a python library, but if there is no other way I could try and write some C# code.
Quick question: How can I access the BN_CLICKED constant and other constants defined for the Win32 API from .NET? Are they defined in some library? Do I have to define them myself? If so, where can I find these values? And are the values version-specific between versions of Windows?
I find the PInvoke Interop Assistant to be really helpful:
http://blogs.microsoft.co.il/blogs/sasha/archive/2008/01/12/p-invoke-signature-generator.aspx.
It has almost everything and can convert the C++ to C#/VB for you. I rarely, if ever, resort to searching google/pinvoke.net anymore.
Here's the MSDN Magazine Article: http://msdn.microsoft.com/en-us/magazine/cc164193.aspx
The original January 2008 MSDN Magazine Article is now only available as a .CHM help file download, linked from the very bottom of https://msdn.microsoft.com/magazine/msdn-magazine-issues. (Column "CLR Inside Out: Marshaling between managed and unmanaged code.")
And here's the download: http://download.microsoft.com/download/f/2/7/f279e71e-efb0-4155-873d-5554a0608523/CLRInsideOut2008_01.exe. The source code can be found at http://clrinterop.codeplex.com/.
You could download the Microsoft Platform SDK and take a look at the header files (*.h). E.g. the BN_CLICKED is defined in the winuser.h file.
Usually, if you just need one or two constants, a Google search and a look at the first few results is also sufficient, since the value is printed there.
http://pinvoke.net/ is an excellent resource for this many common P/Invoke definitions.
The MagNumDB website (by SO user Simon Mourier) is an easy way to look up constants:
http://www.magnumdb.com/search?q=BN_CLICKED
It's kind of a proof-of-concept, but I put together a script that can look up most any Windows API constant. Example usage:
PS > .\Get-WindowsSDKConstant.ps1 BN_CLICKED
0
PS > .\Get-WindowsSDKConstant.ps1 BN_DBLCLK
5
PS > .\Get-WindowsSDKConstant.ps1 WM_COMMAND
273
It requires you to download Visual Studio and the Windows 10 SDK, because behind-the-scenes it compiles a program that looks up the constant.
Finally, here's some answers to the asker's questions:
Are [the constants] defined in some library?
The authoritative source is the Windows Platform SDK
Do I have to define them myself?
They're not built-in to Windows or .NET, which means you'll probably define them yourself (or copy them from somewhere).
And are the values version-specific between versions of Windows?
They're very stable, because otherwise a program compiled for one version of Windows might stop working when a user upgrades to a newer version of Windows. Microsoft goes to great lengths to prevent this from happening.
However, I've seen at least one place where the constants are different depending on what platform/architecture you're compiling on. I wouldn't assume that just because your code works on x86 64-bit Windows, it'll work on ARM 32-bit Windows RT, for example.
I'm writing a WPF program in C# that needs to render a set of files in a file browser to the end user. The ExplorerBrowser control found inside the Microsoft Windows API CodePack contains much of the functionality I need... e.g. thumbnails of different sizes, sorting, browsing, etc...
The catch is that the files are not coming from the disk, but are available over a custom network transfer protocol.
I was originally thinking that I could simply extend the ShellObjectContainer class and ShellObject classes to provide the features I require, by essentially building an Adapter. However I've run into difficulties because these classes use internal constructors.
Overall it's looking like this API is rather hostile to extension, is there anyway to extend these components to do what I need, or am I better rebuilding much of ExplorerBrowsers functionality by creating a custom WPF component, perhaps by extending ListBox?
Yes, this certainly wasn't made to be extensible. Hard to see how you could get anywhere at all unless you create your own shell namespace extension. So that it is viewable in a shell window. Doing so is quite brutal in managed code, the shell's COM interfaces derived from IUnknown are very hard to use. Which is what the wrapper classes in the API code pack is doing to get a browser window in a managed program.
Creating the shell namespace extension is the greater solution, your custom files would be visible in a regular Explorer window as well. But write that kind of code in C++, both because it is so much easier to get the COM code going and to avoid injecting the CLR in any program that uses a File + Open dialog box. Although that is now technically supported by .NET 4.0
Is out there any Pure C# Silverlight video encoding lib?
By video I mean not only pictures compressor but also audio compressor...
So to say I'm looking for some kind of lib not only for compressing but also for sinchronisation etc... so to say I give it a web cam it gives me a conteiner!)
You're certainly not going to want to do this in safe code, unless you've got a lot of buffer memory, as the encoder would run glacially slowly.
One option is to run with elevated permissions, and then you can interact with external COM packages - see http://forums.silverlight.net/forums/p/156112/350144.aspx for some useful links
Here's a link from stackoverflow on the general issue that says pretty much the same thing - Using Native dlls in C# Com wrapper and Use dll in silverlight
If you can create a C# wrapper around calls to any native encoding DLL of your choice, then you can put the wrapper assembly in the GAC and you should be good to go - this would of course mean you need an additional install step to get this assembly into the gac, which is outside the 'normal' silverlight experience
To make this separation easier to implement and use, we introduced what we call the simple sandboxing APIs in the .NET Framework 2.0, which create each application domain with a given permission set for its sandbox and a list of fully trusted assemblies that are not in the Global Assembly Cache (GAC), as all assemblies in the GAC are already fully trusted.
taken from http://msdn.microsoft.com/en-us/magazine/cc765416.aspx - dated, but I believe still accurate
As of February 15, 2010 -- it appears that there is not a built-in way to do this in Silverlight.
Here is a thread that discusses this issue.
Rene Schulte has an example, EdgeCam Shots - Saving Silverlight 4 Webcam Snapshots to JPEG that saves the Webcam stream as sequential JPEG images.
Alright, so I'm working on programming my own installer in C#, and what I'd like to do is something along the lines of put the files in the .exe, so I can do
File.Copy(file, filedir);
Or, if this isn't possible, is there another way of doing what I am attempting to do?
I wouldn't code my own installer, but if you truely want to embed files into your assembly you could use strongly typed resources. In the properties dialog of your project open up the "Resources" tab and then add your file. You'll then be able to get the file using:
ProjectNamespace.Properties.Resources.MyFile
Then you'll be able to write the embedded resource to disk using:
System.IO.File.WriteAllBytes(#"C:\MyFile.bin", ProjectNamespace.Properties.Resources.MyFile);
Honestly, I would suggest you NOT create your own installer. There are many many issues with creating installers. Even the big installer makers don't make their own actual installers anymore, they just create custom MSI packages.
Use Mirosoft Installer (MSI). It's the right thing to do. Make your own custom front-end for it, but don't recreate the already very complex wheel that exists.
UPDATE: If you're just doing this for learning, then I would shy away from thinking of it as "an installer". You might be tempted to take your "research" and use it someday, and frankly, that's how we end up with so many problems when new versions of Windows come out. People create their own wheels with assumptions that aren't valid.
What you're really trying to do is called "packaging", and you really have to become intimately familiar with the Executable PE format, because you're talking about changing the structure of the PE image on disk.
You can simulate it, to a point, with putting files in resources, but that's not really what installers, or self-extractors do.
Here's a link to Self-Extractor tutorial, but it's not in C#.
I don't know enough about the .NET PE requirements to know if you can do this in with a managed code executable or not.
UPDATE2: This is probably more of what you're looking for, it embeds files in the resource, but as I said, it's not really the way professional installers or self-extractors do it. I think there are various limitations on what you can embed as resources. But here's the like to a Self-Extractor Demo written in C#.
I'm guessing here, but if you are trying to store resources in your application before compilation, you can in the Project Explorer, right click a file you would like to add, chose properties and change the type to Embedded Resource.
You can then access the embedded resources later by using the instructions from this KB:
http://support.microsoft.com/kb/319292
in case you simply want to store multiple files in a single file storage (and extract files from there, interact etc.) you might also want to check out NFileStorage, a .net file storage. written in 100% .NET C# with all sources included. It also comes with a command line interpreter that allows interaction from the command line.