Forgive my basic questions, firmware guy here. I have been "gifted" ownership of the driver for a HID device. The current driver is outdated in that it no longer supports the full range of USB pids that this product line supports. I have all of the source code, including a simple text file that includes the list of supported PIDs. I added the new range, and executed several Perl scripts with titles like "IncrementVersions", "BuildINFs" and "BuildWindowsDrivers". I can share these scripts if they're helpful.
The upshot is I seem to have some .inf files that were updated correctly: were up-rev'd, and contain the new range of USB PIDs. But if I right click on one and select "Install", I get a message that says "The system cannot find the file specified". Similalrly, if I got into Dev Man and try to update the driver, Dev Man says I'm already using the best driver for that device.
I do notice that previous versions of this driver were built into setup.exe files. I thought I could install an .inf file directly, but perhaps these setup wrappers contain some necessary functionality? How can I create a setup.exe file from an .inf?
Is any of this helpful in pointing me toward what I might be doing wrong? What can I share that would provide more useful info?
You can install INF files directly but there are three important things to know:
The INF file needs a DefaultInstall section with a line like "CopyINF=your_inf_name.inf". (Actually I think it's not needed on Windows 10 maybe).
You need a CatalogFile directive that refers to a .cat file in the same directory that you have properly signed with your code signing certificate.
You need to right-click on the INF file in Windows Explorer and click "Install" to actually install it.
Since the system is complaining about a missing file, of course you should also read your INF file carefully and make sure all the files it refers to exist somewhere where Windows knows how to find them.
Related
After upgrading Windows 10 anniv. to Windows 10 creators update my own virtual printer (based on unidrv) is unavailable. When I select it in control panel I get a dialog to install a driver (which I ignore) and by pressing cancel you see the printer properties which are readonly (unavailable).
The problem seems to be related to an incorrect .BUD file being generated. When replacing the incorrectly generated .BUD file after the Creators upgrade with a .BUD file (saved after getting the printer driver working) the driver works. (tested this by doing update restore etc..)
Via process monitor I see one access denied followed by lots of success for the CreateFile operation for .BUD files.
So I was wondering: why is that .BUD file generated incorrectly?
While searching I've found this https://superuser.com/questions/17981/why-is-my-current-printer-unavailable-in-office/70477#70477 which guides you to https://web.archive.org/web/20150511125304/https://support2.microsoft.com/default.aspx?scid=kb;en-us;873396
Quote from the KB:
"This problem occurs because you do not have the permissions that are
required to create or re-create a parsed binary printer description
file (.bud). "
Has anyone experience with this? I'm looking for a way to prevent that such a .BUD file for the printer driver is incorrectly generated after a major Windows Upgrade.
Are there things that should be added to the registry or specific files on the pc to make sure that upgrading Windows doesn't make the printer driver invalid?
Or how do you make sure the driver automatically has all correct permissions?
Hopefully there are some experts here on SO that can show the real cause and how to prevent it.
I want to know if there is a specific entry to check in the registry to see if there is a default program associated with a specific file type?
My main example would be a PDF. Documentation in my company is mainly PDF. We want to be able to distribute the latest Adobe Reader because, generally, a lot of the PCs using my company's software will not have access to the internet.
During installation, I want to be able to check if the computer we are installing on already has a program to view PDF files. If yes, carry on. if not, then run the Adobe distribution as part of the install.
I'm focused on Windows 7 PCs, registry entry(ies) I can read programatically to see if, as an example, PDF has a valid program to open it.
No this option not exists. Although HKCR\'PROGID'\shell\open may points to the installed software.
User MC ND have wrong answer. See my screenshot:
During installation, I want to be able to check if the computer we are installing on already has a program to view PDF files. If yes, carry on. if not, then run the Adobe distribution as part of the install.
So I have pdf reader (!!!) with no associations. MC ND you are still thinks, I have no pdf reader?
From console
assoc .pdf to get the "fileType" associated to the extension. Once you have the fileType (ex. AcroExch.Document.11):
ftype AcroExch.Document.11 to get the associated program.
I have standard instalations of some programs, and althou they are freeware and i can download them and install on any machine, things are not that easy always. When system crash and i dont have working machine or working internet connection or lan card or drivers for lan card i always struggle to find them and make them work if some dependency file is not on that version of windows.
What i need is to know is how can i make applications portable so i can run them from my usb or just copy them from my usb on pc and run, what dependency files application require, and what files and where specific application install?
It's a complicated story but let's try to summarize. Starts from the part "why?"
I'm an obsessive guy who seriously "hates" installers. I love to have a clean system without bloated in files reg entries and DLL's. Thats why I make nearly all (at least 97%) of programs that I use portable. I made more than 600 up to today and what I can say is;
You need:
1- A program to watch file system (what included after installation)
I use this. Simple and straight (sorry not freeware, but you can find tons of alternates)
http://www.samsunsegman.com/um/
2- A program to watch registry (what changed or included after installation)
I use this in HTML mode. Free fast and simple. And portable in nature.
http://sourceforge.net/projects/regshot/
Now scan the system with these 2, and than run the installer. After open the installed program and make your settings as you want. And than use this 2 program to find the added files and registry entries.
For files, delete them to trash can and take them back from trash in batch (easy to do like that) to the folder of application.
Registry, open the related branches in registry, delete any entries containing addressings like (plugins folder = c:\prog.... etc) After right click on main branch and select export. This is your reg settings...
3- Download this program http://ctuser.net/?reg2exe
This will convert your reg file to an exe file.
4- Download this application http://download.cnet.com/FilePacker/3000-2216_4-10414081.html
Note: Click on "Direct Download Link" if not you'll cnet will welcome you with their installer :)
And with this program (I use this because have no interference with any application) pack the program that you want to make portable. In wizard, first choose your reg-exe file after main programs file. Launcher will execute them with this order. And in setting choose "delete after terminate" will delete the extracted files on exit.
You can discover the further details. This helps you to portabilitize nearly 75% of simple applications.
5- For complicated programs or complicated needs you even can make home made loaders like
Before executing the app, put the user files under appdata folder (that I hate)
Put settings in registry (even with dynamically modified "path" addresses)
Choose which to execute (x86 or x64)
Execute in admin mode if needed
Execute the app... And when application is terminated...
Delete the settings from registry
Take the user files from appdata folder and put under programs folder (usb etc) back.
Delete left-over files under the system...
I just wrote these last ones to make you understand how far you can go. And for all these extra tricks, I use just and just bat files. And I convert them to exe also with this software. http://www.f2ko.de/programs.php?lang=en&pid=b2e (also free)
All the softwares that I use except "uninstall manager" are free. And with this technique, amazing but some of programs are running even faster.
Actually you can just use JauntePE or portable apps packer things but... Jaunte and similar sandbox making programs are so slow and not compatible with all. Even causing crashes. Portable apps approach is a bit bloated regarding to my strict spped and size standards. That's why I do it myself about for 10 years (yes even people was not talking about portability)
Note: I'm not a programmer, and you also don't need to be to do these.
I never released my portables, and you also shouldn't (read EULA's) for respect to authors.
But never forget to demand portable version from all authors. Force them to quit installers ;)
Best regards
inovasyon did a great job!
If you want to make some portable app that will work on every computer you move it to, then 99.9% of apps can be made portable.
If you also expect the app to not leave any files, folders or registry entries behind and not change or break things on the host PC's setup, then that limits things a bit further.
Apps requiring admin privileges to write to protected areas of the registry or file system will break when used on PCs with locked-down privileges.
Apps requiring services to be installed on the host PC will often leave them behind.
You must to know there are apps that are locked to specific PCs - Microsoft's recent versions of Office are a great example of this. They simply will not run when moved to another PC.
Also, you'll need some tools for making portable app: cameyo, thinapp, boxedapp, portableapps, spoon, app-v and other.
Portable applications will run from a flash drive, and from the computer.
Good Luck!
Here is a primer for setting up a portable app using the PortableApps.com tools. They have a page for developers that is quite helpful for some specifics, but the overall process is not well summarized. Here is the general outline for creating a portable application:
1. Investigate your application's footprints
Find all the files, registry locations and settings of the application you want to make portable (make use of point (1) and (2) in inovasyon's answer, and maybe take a look at Zsoft). It is usally a good idea to fire-up a virtual machine and track the application's changes without much clutter.
2. The PortableApp generator
Download, extract, and open the PortableApps.com Platform, and follow [The system tray icon] →[Apps] →[Get More Apps] →[By Category] to install the PortableApps.com Launcher, and NSIS (Unicode) needed to Portabilize your app. Alternatively, but with some added hassle, download both the PortableApps.com Launcher and NSIS Portable (Unicode version) as standalones.
You can now compile a project by running the PortableApps.com Launcher and pointing it to your project.
3. PortableApp layout and structure
Download the PortableApp.com Application Template (search for it here) to structure the data and files obtained in (1.) according to the specifications. Also, download some apps from portableapps.com for some practical examples of how they are structured, and to learn more about the struggles of portability (such as the substitution of drive letters in settings files to correspond to the movement of a portable drive).
As a "Hello World" example, try portability this simple program: helloworld.bat, with content:
#echo off
echo Hello World > log.txt
It writes all local environmental variables to the log file log.txt. You can play around a bit by trying to writing files to an %APPDATA% subdirectory and see if you can make your project redirect it to a portable directory.
4. Additional usage
If you need to do some additional coding that is not achievable with the default .ini capabilities (such as forcing only one instance of an app), add a NSIS script with file location App\AppInfo\Launcher\Custom.nsh to your project. Note that PortableApps.com's custom code guide incorrectly states the file location as Other\Source\Custom.nsh. It is also quite unhelpful regarding the layout of this script. Rather look at examples from other Apps and learn the NSIS syntax by Google-ing a bit.
I am a windows developer and I had to port an app to Mac. I built it fine and have everything working except my installer. I built my Package file (.pkg) which installs fine and works great on a Mac.
However, I want to move the file to a windows OS over a network to upload it to an ftp server. My ftp client is on Windows. I have done this before without issues on previous .pkg files but I just created one that is acting strange. When I view most .pkg files in windows explorer, they are treated almost like an unknown file type. Windows lets me see the file but I can't really do anything with it. This is fine because I just want to move the file, not use it in any other way.
Unfortunately, I have a new .pkg file that windows strangely treats like a directory instead of just a single file. I can open it and see the "Contents" folder and some internal files/binaries/whatever that I don't want to see. While this is similar to the MacOS functionality, it causes problems because it is uploaded as a directory rather than a file. I just want to drag it to my server and let people download it. Why is this happening?
I have looked online a fair amount and nobody seems to have this issue. It does seem to be permissions related. I saw a good amount of people complaining about "Custom Access" and oddly enough, when I click "get info" on the file, it does say I have "custom access". .Pkg files that seem to display correctly in windows explorer do not have this set. Anyways I would really appreciate the help. I could probably just get an ftp client on the Mac but this does seem really strange and it may help others if there is a solution.
Historically, Mac OS X installer files have been built as bundles, or a directory that appears as a file in OS X. These types of installers will always appear as directories in Windows. However, Mac OS X 10.5 added support for a new format, which is simply the important parts of the installer compressed using xar. Since this format is an archive and not a bundle, it will show up as a single file in Windows.
PackageMaker can produce either format depending on the minimum target version you specified for the package. If you specify 10.5, it will create the new xar format, but if you specify an older version, it will create a bundled installer. If your application will only work for 10.5 and later, you can change the minimum version in PackageMaker by going to Project > Install Properties (Command+I) and changing the Minimum Target dropdown. If you want to support older versions of OS X, then your only choice is to create the bundle version and either compress it as a zip file, or create a disk image to hold it.
I was reading the post Installation file names in Windows Vista when I thought about Installation File Names. I'm a addicted software downloader, and frequently I've got installation names like "setup.exe" or "install.exe", that says nothing about the program to be installed.
I think that an installation file must be like:
Install[ProgramName][ProgramVersion][Platform].[exe|msi|etc]
or
[ProgramName][ProgramVersion][Platform].Setup.[exe|msi|etc]
What your thoughts?
I much prefer descriptive install file names. Sometimes, you want an emergency 'restore' disk to get a machine up and running even without internet connectivity. When all your installs are named "setup.exe", you either have to rename them all, or create a directory with a descriptive name for each one.
An example of where such a disk would have been really handy was when I took my brand new laptop in to work to use while I upgraded my desktop to Vista 64, and then Windows 7. I only have one wired LAN point, so my laptop needed a wireless connection for internet access, to download my installs. I had to download them all on my desktop, and then transfer by flash drive to my laptop. Very inconvenient.
Not sure this is entirely programming-related... but installer files are usually meant to be transient. You download them, run them, and delete them. (Or at least, I think most people do) So it doesn't matter much what the filename is.
I don't think there's any reason not to give the installer a descriptive name... but I certainly wouldn't say it "must" have one.
For CD-Rom based installation, I'd suggest sticking with SETUP.EXE which helps with autorun detecting software to install from the disk.
For downloadable files, just add the appropriate manifest to the EXE and Vista won't have a problem with it. I'd suggest something semi-descriptive, but there's no need to go into great detail unless it's something like hardware drivers that a person may archive off for reuse, otherwise the file name is confusing to non-technical people.