The manifest tool mt.exe is included in the Windows SDK. But the full SDK is large and includes a lot of things as shown in the screenshot. But which of these options actually includes mt.exe?
Ideally I'd like to install just the minimum to get this tool on the system.
It does say in the docs that mt "is available in the Microsoft Windows Software Development Kit (SDK)" - but thats it, without any further detail.
Choose Windows SDK for Desktop C++ x86 Apps.
Additionally, you can then grab the mt.exe binary and put it in a location of your choice, if you don't want to keep the rest of the stuff that comes with that option (say, on a build server). The mt.exe doesn't have any dependencies other than OS dlls.
If you have downloaded the ISO file of Windows SDK, grab the MSI called "Windows SDK for Windows Store Apps Tools-x86_en-us.msi" in the folder Installers
You can just extract (without installing) the content with an administrative installation:
msiexec /a "path_of_your_msi\Windows SDK for Windows Store Apps Tools-x86_en-us.msi" TARGETDIR="Full_Extract_Folder_Path" /qb
Then search mt.exe in your extract folder
Related
So, I've got Windows 10.0.18358.1 installed, latest Visual Studio (17, not bothering with 19 as of yet), updated (Insider) Windows SDK which should include the DX12 SDK.
And, yet, I have no DXSDK_DIR environment variable set.
I can see all of the DX and D3D headers and libs in the windows kits folder, but their distribution doesn't really correspond to a typical include/bin/lib structure.
Suggestions on how to correct this? I'd settle for copy of anyone's set output
that has this working.
(DirectML tag is because that is the feature that I require, and the source of all of this insanity.)
The DXSDK_DIR variable was only used by the legacy DirectX SDK and the 'beta DirectX 12 SDK' test vehicle, it's not used by the Windows 10 SDK as the standard WindowsSDKDir already includes the required headers & libraries.
If you are building with the Visual Studio build system, you don't have any special setup to use the DirectX 12 headers as they are all in the path already. Likely, your project is set to use the 10.0.17763 Windows 10 SDK by default, so to use the Windows 10 Insider SDK, you'll need to modify the project settings <WindowsTargetPlatformVersion> element to reference the newer 10.0.18xxx version.
If you are using some more manual build system, then you should use the include paths for the Windows 10 SDK side-by-side structure:
%WindowsSdkDir% is typically "C:\Program Files (x86)\Windows Kits\10\"
%WindowsSDKVersion% is something like "10.0.17763.0\"
%arch% is "arm", "arm64", "x64", or "x86'
INCLUDE=%WindowsSdkDir%include\%WindowsSDKVersion%shared;
%WindowsSdkDir%include\%WindowsSDKVersion%um;
%WindowsSdkDir%include\%WindowsSDKVersion%winrt;
%WindowsSdkDir%include\%WindowsSDKVersion%cppwinrt
LIB=%WindowsSdkDir%lib\%WindowsSDKVersion%um\%arch%
See Microsoft Docs and this blog post
The Windows 10 SDK does not include utilities which are instead shared source. For D3DX12, you can obtain the latest header from here
You may also want to look at DirectX Tool Kit for DX12, DirectXTex, and DirectXMesh
For historic and usability reasons, DirectXMath is part of the Windows 10 SDK, but you can also get the latest version from GitHub. The recent Windows 10 SDKs also include the HLSL compiler/D3DCompile API including both the older FXC.EXE and the new Shader Model 6 DXC.EXE.
You may also find the Visual Studio templates on directx-vs-templates useful.
I would suggest reverting to the previous build and flagging the issue in the Feedback Hub. Also, if you haven't already, run chkdsk before and after install, just in case.
Is Inspect a part of the Windows 10 standalone SDK?
Is there any alternative application to "inspect" for windows 10?
I want to install "inspect" tool on my machine running windows 10 build 10586 (for testing purpose).
According to Inspect documentation on MSDN it is not described if it is a part of win 10 sdk also or only upto win 8.1.
Also is there any alternative tool for "Inspect" to debug on windows 10?
Since 10.0.15063 the directory of the tools has changed. See the changelog:
To improve the developer experience, tools and metadata will lay down in versioned folders.
This will allow developers to isolate the SDK and tools between
releases.
You have to put the version of the Windows SDK between bin and x64 (or x86 or arm)
For me inspect is in the folder C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64
The folder C:\Program Files (x86)\Windows Kits\10\bin\x64 (without the SDK version) exists, but does not contain the inspect tool.
Needed Components for "Inspect":
Inspect is, indeed, included in the Windows 10 "standalone SDK" available from Microsoft here. Note the installer stub allows you to download several "features" (additional toolkits and utility packages) besides the Windows SDK proper. If all you want is Inspect, you can save yourself downloading about 300MB (650MB installed) of unnecessary packages by deselecting everything except "Windows Software Development Kit":
As for an alternative to Inspect, this answer suggests Windows Detective. Not having used the tool, I can't speak personally to its safety or suitability for the purpose, so caveat emptor, YMMV, May the Force Be With You and all that.
If you are using Visual Studio 2017, you can also install Inspect via the Visual Studio Installer.
All you need is to install the following feature, or a later version:
Windows 10 SDK (10.0.15063.0) for UWP: C#, VB, JS
After doing that you should find inspect.exe in the following location:
C:\Program Files (x86)\Windows Kits\10\bin\<version>\x64
In windows 10, Inspect.exe is available at C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\arm64.
Steps in Jul 2022
https://developer.microsoft.com/en-us/windows/downloads/windows-sdk/
Download the 22621.1.220506-1250.ni_release_WindowsSDK.iso and launch it, windows 10 will automatically mount it as D.
Install this: d:\Installers\Windows SDK for Windows Store Apps Tools-x86_en-us.msi
After that, inspect.exe will be available in C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x86\inspect.exe
If you can't find the tool in the Windows 10 SDK, you should be able to download and install the Windows 8.1 SDK from the SDK archive page:
Windows and Windows Phone SDK archive
Inspect is available here: C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64. Based on version changes you can find it in one of the versions under the x64 folder.
Regarding the second part of the question, about an alternative, I've tested an interesting one that works very well, FlaUInspect. Is targeted for an "automation perspective", giving details useful for writing automated tests for example.
Is open source under an MIT license. Can be found on GitHub.
2 files required for the MS DHTML control to work properly were removed from windows vista (and win7, 8 presumably) for security reasons.
These are the DHTMLED.ocx and TRIEdit.dll.
Microsoft now supply a downloadable msi file, dhtmled.msi, which will install and register the 2 components into the following directory:
%windir%\Program Files\Common Files\Microsoft Shared\dhtmled\
I would like to build this into an inno script.
Should I run the installer on my machine first to get hold of the ocx and dll files and have separate lines for each in the inno script or should I incorporate the msi file into the script?
Also what flags should I use to prevent installation on win xp or earlier and when the files are already present?
Thanks
See Replacing the DHTML Editing Control in Windows Vista and Beyond
For new applications, you can ship the installer as part of your product (with appropriate licensing) and chain to it from your own installer. The installer can be run silently and without adding an item to the installed-programs list in Windows. (For details, see the documentation for MsiExec.exe.)
However, we recommend that the installer allow the DHTML Editing Control to be added to the installed-programs list. In addition, when your application is uninstalled, do not uninstall the control; instead, allow customers to uninstall it separately if they want.
Note that this method of installation does not provide logo-compliant installation.
The method that is compliant would be to list this as a prerequisite that the user manually installs before running your installer.
I haven't seen anything the permits redistribution of the naked libraries under any circumstances.
I have the following autorun.inf
[Autorun]
action="Blah, Inc."
open=marketing.exe
icon=blah.ico
label="Blah, Inc."
On Vista, the autorun dialog shows "Publisher not specified". How do I specify a publisher?
Bogdan is right: You need to sign your executable.
You can use SignTool from Microsoft for this. Taken from the MSDN:
SignTool tool is a command-line tool that digitally signs files, verifies signatures in files, or time stamps files. (...) The tool is installed in the \Bin folder of the Microsoft Windows Software Development Kit (SDK) installation path.
SignTool is available as part of the Windows SDK, which you can download as part of the Windows SDK for Windows Server 2008 and .NET Framework 3.5.
You specify the publisher by signing your executable file, not by writing it in the autorun.inf file.
How to do it...beats me, I'm a Java developer. Maybe someone else can tell you how.
We are working on a winforms app in Visual Studio 2005 and the setup project we created output both an MSI and an EXE. We aren't sure what the EXE file is used for because we are able to install without the EXE.
It's a bootstrapper that checks to make sure that the .NET Framework is installed, before launching the MSI. It's pretty handy.
I suggest using something like SFX Compiler to package the two together into one self-extracting .exe and then launch the extracted setup.exe. This way you retain the benefits of the bootstrapper, but your users only download a single thing.
Edit: also see
The official line: MSDN documentation
Some bootstrapper customization: some guy's blog post about what he did
The EXE checks if Windows Installer 3.0 is present and downloads and installs it if it's not. It's needed only for Windows 2000 or older. Windows XP and newer all have Windows Installer 3.0 out of the box.
Other prerequisites, like .NET, are checked for by the MSI itself.
I think the EXE is just a wrapper/bootstrapper for the MSI in case you don't have Window Installer. If you have the requisite Windows Installer version installed then the MSI should work fine on its own.