I am currently working on a project to perform disk defragmentation in Microsoft Windows environment. For that I want to use the in-built functions of the Windows defragmentation utility. I read somewhere that Windows uses "dfrgres.dll" file to perform defragmentation. So, I want to add "dfrgres.dll" file as a reference in my project. But I am not able to do so. This is the error message which I am getting when I try to add the specified DLL into my project:
"A reference to '...\dfrgres.dll' could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component"
Please tell me where the problem is...or is there any other way to do it...??? Are there any other open source resources available over the internet for defragmentation...???
Regards,
Mr. Elusive
There is no dedicated DLL or COM server to perform defrag, the low-level interface uses IOCTL codes to talk to the device driver. Briefly described here.
There's a Microsoft employee blog post that proposes a C# interface. No idea if it still works on later versions of Windows.
Related
This Stackoverflow question asked how to modify the version information in an existing binary (DLL or EXE). The answer was to use Visual Studio. I tried on a 3rd party DLL our PC supplier gave us to read system metrics (such as battery voltage or motherboard temperature). The supplier had neglected to add any version information to the DLL. This proved disturbingly easy to do and the version information when viewing file properties looks absolutely legitimate.
This Superuser question shows how to use a fantastic utility called Autoruns to see what is starting up and running on your computer. One of the high-rated answers suggested being suspicious of DLLs or EXEs where the Publisher was unknown or blank.
Now I ran Autoruns myself and identified a Java DLL not currently loaded into memory. The DLL was loaded into VS and the "Company Name" modified from "Oracle Corporation" to "HonkyTonks". Reloading Autoruns...and lo and behold, the "Publisher" now shows "HonkyTonks"! Holding the mouse over the DLL in Windows Explorer also shows version information with any modification I care to make.
So my questions are:
1) Is the suggestion to look for Company Name/Publisher useful (in terms of security)?
2) This looks to me like a security loophole because many otherwise competent computer users may see "Microsoft Corporation" or similar in the version information and assume the file is legit. Is this a known loophole and if so does it apply to all versions of Windows and possibly other OS? Am I just behind-the-times and one should never trust this information?
3) Can you programmatically detect whether the version information had been modified in this way?
4) Can you lock down the version information in our own binaries so that it cannot be modified so easily by someone else?
Thanks.
In terms of security, the version information is mostly unuseful. It
provides only the basic information about a publisher and as you
mentioned can be easily forged.
Yes, that's why in Microsoft's .Net Framework you can digitally sign assemblies and executables. In this case, even modification of a version information will lead to denying of execution or loading of a signed binary. And the only way to fake the assembly is to steal the private key used to sign this
assembly.
No. It's only possible if you have signed the executable or DLL. But in classic Windows (not MS .Net) it's almost impossible to do. Because you need to store the public part of the key used for verification in secure place. Otherwise, the hacker can replace public key with his own and your verification program will fail to detect the fake.
You can sign the binary and put the digital signature inside of it or a separate file. And validate the signature against the binary before loading it. And you must secure the public key storage.
I'm trying to write a plugin for Office on Mac to match some functionality I have on Windows. I've been working with Word 2011 for Mac to create a PoC. I can get my library loaded into Word in various ways, but I'd really like something clean and (at least somewhat) supported.
I've discovered a WordPDE.plugin inside the app bundle, but DYLD_PRINT_LIBRARIES reveals that the plugin is never loaded under typical operation (Start app, create doc, type content, save doc, quit app.) I placed a dummy plugin beside WordPDE.plugin only to have it ignored by Word.
I also see that the Office apps include a MicrosoftComponentPlugin.framework but the information reported by class-dump doesn't help determine how to write a "Microsoft Component Plugin" nor how it might actually get loaded.
Ultimately, I can get my library into Word by asking dyld to do it, or by modifying load commands in the executable, but I'd much prefer going a cleaner route with some kind of plugin. Is there anyone with any information about how Word for Mac loads and uses this plugin and/or the mentioned framework?
I need to find the product version of an installed application using the product code GUID. Is there a way to do this using a simple API call of some sort? I have found ways to do it using P/Invoke and the WindowsInstaller namespace, but I am trying to avoid using P/Invoke.
The Windows Installer exposes Win32 API functions (P/Invoke) as you have discovered. It also has COM automation interfaces that wrap these APIs but I'm sure you can guess is this is even less elegant. Windows Installer XML (WiX) Deployment Tools Foundation (DTF) has an MSI interop library that wraps it as managed code but I'm sure you can guess what it's doing under the covers: P/Invoke.
There are ways of getting it from the registry but this is not the official API and is less elegant IMO.
So to answer your question, you are already doing it in a very good and professional way.
If you want to get sneaky you can look through the registry to figure it out. When an MSI is installed windows creates a set of registry keys under:
HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\<munged-ProductCode>
or
HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\<munged-ProductCode>
(depending on your machine/MSI bitness)
Under that registry location there should be a registry value named "ProductVersion". The trick is to know how to 'munge' a windows GUID (see http://www.vmwareinfo.com/2011/09/surgically-eliminating-windows.html).
I'm looking for a missing COM interface X which I suspect is defined in Y.dll. I can peek at this presumptive interface using
grep X Y.dll
which says "matches". Hurrah, suspicion confirmed!
Alas, when I use the Object Browser in Visual Studio Express, trying to add Y.dll to my Custom Component Set, I get the error: "Some components could not be browsed" in a pop-up window.
So what are the reasons I can't browse this dll? Can the COM interfaces deliberately or accidentally be protected, hidden, secured, or obscured? Obviously I need a primer!
Officially, all Microsoft knows about this seems to be generally devoid of insight:
This error generally occurs when you attempt to add a file type that does not support object browsing, such as .htm
and .txt files, in the Component Selector dialog box. The Object Browser supports file types such as .bsc, .olb,
.tlb, .dll, .exe, and .ocx.
Seriously, what are the reasons for a dll or exe to not support object browsing? Any pointers to tutorials or books would be appreciated by this beginner! Thanks.
COM Object browsers rely on metadata (type libraries) exported by COM servers (dll, exe, ocx, etc).
The problem is that COM Servers are not required to export any metadata about which interfaces it implements. Unfortunately I have found quite a number of such servers (so one needs to know which CoClasses, Interfaces, etc are supported by other means).
Check if your COM Server (y.dll) contains a resource called "TYPELIB" similar to:
Hope this helps.
Maybe i don't have any knowledge of how referencing works in VB6. I have an application written on visual basic 6. I've added Microsoft Scripting Runtime and Data Access Object 3.6 as references. I wanna know which component should be placed in others systems to prevent issues related to these two references. I mean if the user has windows XP, Vista,7 or 8 does my application will run correct in that versions of windows? (considering these two references)
You will have to include DAO 3.6 redistributable files, as explained on the Microsoft support page; However, your application will work properly on all of these target Windows versions, if no other potential issues exists (e.g. other incompatible used ActiveX control)
Have your clients install the EXEs created by Microsoft:
For Microsoft Scripting Runtime, check out the "Cause" Section of this article.
For DAO, check out the resolutiion section of this article.