I am creating an installer which checks the registry for softwares/ components that are not installed and installs them if needed. The problem I am having is that the software I need to run launches correctly if I install the latest DirectX End-User Runtime from the DirectX End-User Runtime web installer on a fresh copy of Windows(http://www.microsoft.com/en-au/download/details.aspx?id=35).
The error I get if not installed is "The program can't start because d3dx9_43.dll is missing from your computer". Now even in a fresh install of windows, the DirectX registry entry from HKEY_LOCAL_MACHINE\Software\Microsoft\DirectX shows "4.09.00.0904" for the Version key.
So my question is, where do I look in the registry to check whether all components from the DirectX End-User Runtime are installed.
Really appreciate the help.
You didn't mention what installer, script, or programming language you were using. That would be helpful to know.
If you aren't worried about download size, the easiest thing might be to just always install the DirectX Runtime blindly. It won't hurt to install it if it's already there.
Here's some other things you can consider:
If you are on Vista or later (including Win7, Win8, Server 2K8), then you likely don't need to install anything. As these operating systems likely ship with the binary pre-installed. Ditto for XP SP2 and later. Is your "fresh copy of Windows" something newer than XP?
Another simple idea is to just search for the existence of d3dx9_43.dll in either the Windows\System32 or Windows\SysWow64 directory.
Programatically, you can have your Installer code detect for the installation of the DLL as follows
#include <windows.h>
BOOL HasD3DX9()
{
HMODULE hMod = LoadLibrary("d3dx9_43.dll");
return (hMOD != NULL) ? TRUE : FALSE;
}
Related
I want to support older Windows versions, but non updated 7 and pre 7 operating systems do not support sha256 code signing, so they cannot detect that the executable/file is properly digitally signed.
My questions are:
How can i check if a system has this update (KB4474419) installed, or basically check if it supports sha256, without causing false positives (for example detecting new windows 10 machines as not having the update by mistake)
How to install this update in the background, without user knowing, and check if installation was successful (in order to see if we should restart the machine or not, in case it was successful) ?
(I want to implement it using c/c++, so native windows APIs are available to solve this)
WUA defines interfaces and objects that are accessible from Visual Basic, Visual Basic Scripting Edition (VBScript), JScript, and from C and C++.
I suggest you could try to use wuapi.h header. This header is used by Windows Update Agent API. And there are some COM interfaces that can be used from C++.
I need to install a DLL on Windows and OSX, it will be used by several apps and dlls placed allover the system, but I'm 100% sure it will always be my apps and I don't need any kind of versioning, meaning that if the DLL is replaced by a newer version (or older for that matter), it will work just fine. I also need 32-bit and 64-bit versions.
It looks like these are the proper paths:
OSX : /usr/lib (merged binary for 32 & 64)
Windows: C:\Windows\System32 (here the sources vary)
On OSX it seems working fine. On Windows however it doesn't. I need to support Windows XP,7,8... And on Windows 8.1 it sometimes just didn't work - the file was clearly there, but systém said the DLL is missing. It also seems like the folder for 32-bit (SysWOW64) and 64-bit (system32) are actually pointing to the same location, so I assume Microsoft has been "fixing" the naming mess.
Anyway one location it always worked is here:
C:\Windows
but it doesn't seem to be designed for that. So how is it?
I am trying to install Sheridan controls (ActiveThreed 2.01) on Win7 64-bit, but evidently it is a 16-bit installer so it won't execute.
What would be the best way to get round this problem?
Can anyone comment on whether http://homepage3.nifty.com/takeda-toshiya/msdos/index.html would be helpful?
It took me months of googling to find a solution for this issue. You don't need to install a virtual environment running a 32-bit version of Windows to run a program with a 16-bit installer on 64-bit Windows. If the program itself is 32-bit, and just the installer is 16-bit, here's your answer.
There are ways to modify a 16-bit installation program to make it 32-bit so it will install on 64-bit Windows 7. I found the solution on this site:
http://www.reactos.org/forum/viewtopic.php?f=22&t=10988
In my case, the installation program was InstallShield 5.X. The issue was that the setup.exe program used by InstallShield 5.X is 16-bit. First I extracted the installation program contents (changed the extension from .exe to .zip, opened it and extracted). I then replaced the original 16-bit setup.exe, located in the disk1 folder, with InstallShield's 32-bit version of setup.exe (download this file from the site referenced in the above link). Then I just ran the new 32-bit setup.exe in disk1 to start the installation and my program installed and runs perfectly on 64-bit Windows.
You can also repackage this modified installation, so it can be distributed as an installation program, using a free program like Inno Setup 5.
You can't run 16-bit applications (or components) on 64-bit versions of Windows. That emulation layer no longer exists. The 64-bit versions already have to provide a compatibility layer for 32-bit applications.
Support for 16-bit had to be dropped eventually, even in a culture where backwards-compatibility is of sacred import. The transition to 64-bit seemed like as good a time as any. It's hard to imagine anyone out there in the wild that is still using 16-bit applications and seeking to upgrade to 64-bit OSes.
What would be the best way to get round this problem?
If the component itself is 16-bit, then using a virtual machine running a 32-bit version of Windows is your only real choice. Oracle's VirtualBox is free, and a perennial favorite.
If only the installer is 16-bit (and it installs a 32-bit component), then you might be able to use a program like 7-Zip to extract the contents of the installer and install them manually. Let's just say this "solution" is high-risk and you should have few, if any, expectations.
It's high time to upgrade away from 16-bit stuff, like Turbo C++ and Sheridan controls. I've yet to come across anything that the Sheridan controls can do that the built-in controls can't do and haven't been able to do since Windows 95.
I posted some information on the Infragistics forums for designer widgets that may help you for this. You can view the post with the following link:
http://forums.infragistics.com/forums/p/52530/320151.aspx#320151
Note that the registry keys would be different for the different product and you may need to install on a 32 bit machine to see what keys you need.
I am mostly posting this in case someone comes along and is not aware
that VB2005 and VB2008 have update utilities that convert older
VB versions to it's format. Especially since no one bothered to
point that fact out.
Points taken, but maintenance of this VB6 product is unavoidable. It would also be costly in man-hours to replace the Sheridan controls with native ones. Simply developing on a 32-bit machine would be a better alternative than doing that. I would like to install everything on Win7 64-bit ideally. – CJ7
Have you tried utilizing the code upgrade functionality of VB Express 2005+?
If not,
1. Make a copy of your code - folder and all.
2. Import the project into VB express 2005.
This will activate the update wizard.
3. Debug and get the app running.
4. Create a new installer utilizing MS free tool.
5. You now have a 32 bit application with a 32 bit installer.
Until you do this, you will never know how difficult or hard it
will be to update and modernize the program.
It is quite possible that the wizard will update the Sheridan controls
to the VB 2005 controls. Again, you will not know if it does
and how well it does it until you try it.
Alternatively, stick with the 32 Bit versions of Windows 7 and 8.
I have Windows 7 x64 and a program that will not run. However,
the program will run in Windows 7 32 bit as well as Windows 8 RC 32 bit.
Under Windows 8 RC 32, I was prompted to enable 16 bit emulation
which I did and the program rand quite fine afterwords.
I had 32-bit software with a 16-bit installer that I couldn't unzip. I solved it with otvdm which allows you to run windows 1.x, 2.x, 3 programs on win64. In fact, otvdmw allows you to select the program to run (otvdm is command-line).
16 bit installer will not work on windows 7 it's no longer supported by win 7 the most recent supported version of windows that can run 16 bit installer is vista 32-bit even vista 64-bit doesn't support 16-bit installer....
reference http://support.microsoft.com/kb/946765
Bottom line at the top: Get newer programs or get an older computer.
The solution is simple. It sucks but it's simple. For old programs keep an old computer up and running. Some times you just can't find the same game experience in the new games as the old ones. Sometimes there are programs that have no new counterparts that do the same thing. You basically have 2 choices at that point. On the bright side. Old computers can run $20 -$100 and that can buy you the whole system; monitor, tower, keyboard, mouse and speakers. If you have the patience to run old programs you should have the patience to find what you are looking for in want ads. I have 4 old computers running; 2 windows 98, 2 windows xp. The my wife and I each have win7 computers.
All of the documentation I have seen regarding distribution of Adobe AIR apps suggests that an installer is required to be run in order to get the runtime and the app onto a system.
The environment I am working in requires the AIR runtime, the AIR app and associated DLL's (it will be calling Windows native processes) to be transferred to a clean system and this needs to happen without running an install package. Ideally in the form of just copying the necessary files (DLL's, resources etc..) to where they need to be. Scripts can be used for tasks like adding registry keys and similar requirements. The build needs to be automated in the form of a copy, hence why no installer packages are suitable.
Does anyone know whether this is at all possible with Adobe AIR? Note, the app is Windows-only so cross platform is not a requirement.
Thank you in advance for your help
I'm adding more details in this answer.
In order to use NativeProcess your app must be an EXE compiled by ADT using "extended-desktop." I didn't find much documentation ont his, but a normal air app installs silently like this
C:\AdobeAIRInstaller.exe -silent -eulaAccepted "C:\yourApp.air"
Since the ADT compiled EXE already contains air, you can acutally just do this
C:\yourApp.EXE -silent -eulaAccepted -location "\"C:\WhereToInstall\""
I don't believe you need a redistributable license to do this... but I could be wrong. It's easy to get and free so you might as well.
Where yourAPP.EXE is the extended desktop AIR app compiled by ADT. For compiling an EXE by ADT see: http://help.adobe.com/en_US/air/build/WS789ea67d3e73a8b22388411123785d839c-8000.html
No; this won't be possible. You'll have to install the AIR Runtime on the Windows machine to run an AIR app. And I expect the AIR app won't actually run w/o running the AIR App installer.
You may be able to look into alternate non-AIR options to turn SWFs into EXE. Zinc is one such software to do that.
Or it is possible you can create an invisible installer. I believe if you sign up for redistribution of the AIR Runtime there is a way to make the runtime installer "invisible". I'm not sure about the app, though.
I have a pretty generic 64bit driver based on bulkusb.sys in WDK. It's been working for years with an embedded program, but now it is needed to work on Vista 64.
From all the documentation I've tried to look through there doesn't seem to be anything affecting it, except compiling it for the 64bit environment, and yet when I compile it with the AMD64 build environment, I get "driver not intended for this platform" error message when it's trying to open the sys.
What could be the solution for this?
Update:
What exactly do you mean by "trying to open the sys"? In the log, when it tries to run the sys file of the driver(not error in the inf) it fails.
What WDK version are you using? 7600.16385.0
Are both building and trying to deploy on the same Vista x64 machine?
No, I'm building on 32bit xp, but I don't see how it matters, since I use the correct build environment.
Is your driver signed with a cross-signed certificate? No, I've tried enabling unsigned drivers, and it didn't help, but I'm also not sure what will be going on with this subject at all, and if you can give me some info on that as well, it will be welcome.
Is the right build environment chosen (chk/fre/amd64/win2k)?
I've used chk-vista-amd64. Since it's for vista 64bit...
If your code are based on bulkusb.sys in WDK, you should just try to compile the code of Bulk USB device driver for Intel 82930 USB test board included in C:\WinDDK\7600.16385.1\src\usb\usbsamp\sys of WinDDK. Then if it could be started in your environment, try to compare the code from WinDDK which you used (for yeas) as a template of your driver with the current version of usbsamp from WinDDK 7600.16385.1. You will see which changes where made in usbsamp. Probably the same changes you should do in your program.
I could not give more exact answer, because I am trying to find an error in a code which I don't see. It seems to me not easy.
Make sure that you're removing the copy of the driver in
%WinDir%\System32\DriverStore
Because otherwise newer versions of the driver that you try to install on the system won't be used.
There are 2 ways to do this:
1) Plug-in your device and install the incorrect driver, and remove using Device manager, but when removing, use the mouse-menu and not the delete key, and check the box about "removing the driver"
2) Locate the OEM##.inf file corresponding to your driver in %WinDir%\Inf.
using an elevated command line windows (i.e. Run as Admin) use
pnputil -d oem##.inf
Now you can install the new version of your driver.