I just installed the latest SDK(10.0.10586.0) and was wondering if I can delete the libraries from the older Windows 10 SDKs(10.0.10240.0 and 10.0.10150.0)?
Or is there a safe way or a program to do this?
You can uninstall the older versions via Add/Remove Programs. It maintains a different entry for each version.
If storage space is a pressing issue for you, you can proceed to delete the older SDKs. Deletion can be done via program files in pre Windows 10 Creators Update builds or from Settings in newer Windows 10 builds.
However an ideal software should provide a good backward compatibility at least within a major version of Windows which at this point is Windows 10.
Imagine someone with an early build of Windows 10 being unable to download your app from the store. You lose users/customers just because they have to update their OS all the way which many avoid altogether.
Keeping the older SDKs will allow you choose a minimum Windows 10 build that your app should support and hence allow installation from devices on those builds.
If you need to target specific builds of Windows, then you might want to keep older SDKs around. As new SDKs come out there may be functionality added that isn't supported by older builds of Windows, then your code will not run on that build. Generally you want to use the newest SDK available that works for your targeted audience.
I have many versions and I am not sure which to delete. I found How to move Windows Kits Folder to other disks? So if space is the problem then you can move the Windows Kits folder to another drive. That post says to move the Windows Kits folder to another drive and then with administrator privilges use the following:
mklink /J "C:\Program Files (x86)\Windows Kits" "D:\Windows Kits"
That creates a junction; joins the folder in the C: with the folder in the other drive.
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.
I just installed windows 8 and microsoft visual studio 2012. The problem comes when I try to run a program, it tells me:
the program can't start because glu32.dll is missing from your computer. try reinstalling the program to fix this problem
But I have already placed the glu32.dll in the locations that it should.
The graphics drivers shipping with Windows 8 lack proper OpenGL support. You must download the drivers from your GPU vendors website directly and install those.
Also when manually adding missing DLLs you should not add them to system directories, but into right into the directory of the application's .exe files.
I'm using Microsoft Visual Studio 2008 (VC9) to compile a project that has a .dsw file. I already have the 2010 and would prefer to use it, but it seems this dsw was built for 2008.
I'd like to compile and produce a binary that's also compatible with Windows 7. My questions:
if I compile with 2008, will the resulting binary be compatible with Windows 7? I'm not sure at which version of VS did Windows 7 support start.
or does this have nothing to do with the VS version, and is instead related to the Windows SDK? If that's the case, can I use VS2008 with a newer Windows SDK?
Can someone please clarify.
Microsoft has a great backwards compatibility "story", so pretty much anything you compile with any version of Visual Studio/Visual C++ will be compatible with Windows 7. The same may not neccessarily apply in reverse, i.e. if you use an API that's introduced in Windows 7, your application will error when you try to run it on prior versions of Windows.
There are a couple of things to consider though:
If the project was originally written to target Windows XP or earlier, it may fall foul of UAC
There are changes to directory structures (such as %systemdrive%\Documents and Settings becoming %systemdrive%\Users) that are fairly well handled by the link that Windows 7 creates in the root of `%systemdrive%, but you may fall foul of these.
VS2010 includes version 7.0 of the Windows SDK and VS2008 does not. You need Windows SDK v7.0 if you want your app to take advantage of Windows 7 features like jump lists.
Since you already have VS2010 installed, you can just change your include file / lib file paths in VS2008 to point to the Windows SDK v7.0 instead of the default one provided with VS2008. This is assuming you need that version of the SDK.
You do not need the latest Windows SDK if you do not plan to use the latest Windows 7 features like ribbons and jump lists. If you are building your app for the lowest-common-denominator OS (i.e. Windows XP), then really you should be fine using VS 2008 with default settings.
The other concern is, if your code was originally written before Windows Vista came out, it is likely that it will not work properly on Windows 7 unless it is run in Administrator mode, which is something you want to avoid. The only way to fix that is to rewrite much of your code to avoid writing to certain protected directories and avoid using certain APIs that require Administrator privileges.
Windows SDK is well backward compatible. See binary compatibility report between Windows 6.0 and Windows 7.0 on x86_64 generated by the abi-compliance-checker tool for the detailed comparison.
Reports for other Windows versions are here: https://abi-laboratory.pro/index.php?view=windows
I found Vb6 tools package and deployment. I used it and created a package or setup file from my running vista operating system. Later when i tried deploying it in clients computer with winxp, it asks for update of system file and ask to restart. The process never ends just ask for update and restart. how should i create setup file to avoid this problem?
Edit:
If i create setup file in Win98 and deploy it in clients Vista or winxp then it runs fine...
There is a very good chance you are trying to deploy system files that you shouldn't. Typical examples include MSVCRT components.
You receive multiple "System files are out of date" error messages when you install a Visual Basic 6.0 application
Using Win9x can mask the problem because ancient versions are packaged. During installation either setup1 will detect that newer versions are already in place or Windows will fend them off via System File Protection. Vista is much better at this than XP was.
Yes, the PDW is old. For that reason you should seek out the MSKB articles on usage tips, newer information, and on manually updating the files PDW uses as guidance (its REDIST folder, VB6DEP.INI and the .DEP files that accompany many controls).
Best practices for deploying Visual Basic 6.0 applications is a good generalized starting point.
Many of these sorts of issues have been answered over the years since VB6 and the PDW were released.
The VB6 package and deployment tool is really dated. It doesn't play well with some of the new security features.
It's probably trying to install old copies of the VB6 runtimes and then Windows is restoring its own copies.
It's been a while, but can you remove the VB6 runtime files from the files to deploy in the Package and Deployment Wizard? If so, do so. As long as the computer being installed on has the latest service packs it will already have the VB6 runtimes on it.
If that doesn't solve your problem then check what other system files your deployment project has in it. In most cases you won't need to deploy any system files as modern, patched systems should have them all. There are a few activeX controls that may not be on modern systems, but those shouldn't cause these endless restart problems.
Alternatively, try another install technology. You could create a setup project in modern versions of Visual Studio. Alternatively there are some very good open-source and commercial products.
I've used this one quite successfully in the past:
http://nsis.sourceforge.net/Main_Page
I'm using msscript.ocx in my application which is an activex scripting host for windows.
Although I want to be able to use the same for XP embedded(XPe) which's highly customizable.
1.I want to know whether on XPe, msscript.ocx can be optionally installed or not?
2.Where does it get installed from, IE?
3.Or is it a windows core component which gets installed during the XPe setup?(I know one can unregister it, but can it be an optional installation)
Answering any or all of these questions will be of great help to me.
Thanks in advance.
Sam.
Microsoft's documentation of the MSScript.ocx library is somewhat contradictory on this issue. The short answer is, starting with Windows 2000, the MSScript.ocx library became part of the Windows OS. Subsequent service packs for Windows 2000, XP, and 2003 included bug fixes (1,2,3) for this library. Since that time, the library has remained part of the 32bit portion of Windows and is still included with Windows 7/2008 R2. Even 64bit versions of Windows still include msscript.ocx with WOW64 in C:\Windows\SysWOW64.
For a little history of this library's distribution keep reading.
Msscript.ocx was originally included on the Visual Studio 6 CD as a "optional" library - optional meaning it had to be manually installed. While the library was part of Visual Studio, it was migrated to being part of the Windows OS starting with Windows 2000.
This is where the confusion comes into play. Since msscript.ocx is considered to be a component of both VS6 and Windows 2000, updates were distributed in service packs for both. Even after the last service pack for VS6 was released, additional bug fixes needed to be distributed for older OS's, so a separate download was created specifically targeting Windows 95, 98 and NT4.
This download is targeted for older OS's for the simple fact that it had become a part of the OS in "modern" versions of Windows. If you are using Windows 2000 or greater, the download is unnecessary and - in my experience - can cause compatibility problems.
I think it is not shipped with Windows XP(not a 100% sure)...
But the best choice is to ship it with your installer(even if it was shipped, it can be removed). About the installing - you can put it where you want (in the program folder in Program Files is ok), the important thing is to register it.
The best choice for making installers - Wix
EDIT: reference
The Script control ships with Visual
Basic 6.0; however, Visual Basic 6.0
setup does not install the Script
Control for you. The control is
located in the CD directory
Common\Tools\VB\Script. To install the
script control, try the following
steps:
I think this answers your question....
For those having issues getting MSSCRIPT.OCX to work do the following:
Go to References in Project settings:
Microsoft Script Control 1.0
Microsoft Scripting Runtime
Microsoft Scriptlet Library
Check all those on.
you'llneed to change your development environment to produce a 32 bit version of your appliation, which for most apps won't matter.
For this goto Project,
then select Properties,
select Compile,
Target CPU: x86
In your code, and i'm using visual studio 2019,
' by using the references above the ScriptControl
' should become available for inclusion into your source c
Dim ms As ScriptControl = New ScriptControl
ms.Language = "JavaScript"
ms.Reset()
Try
ms.ExecuteStatement(RichTextBox1.Text)
Catch ex As Exception
MessageBox.Show(ex.Message)
End Try