My program needs to locate an existing GhostScript install, and run gswin32.exe (or the 64-bit version if installed) with some command-line options to do a silent conversion of PS to PDF. How should I go about this? I see they add some registry settings under HKEY_LOCAL_MACHINE\SOFTWARE\GPL Ghostscript\9.07, but I only see a LIB path (which has several paths) and a DLL path, nothing for the EXE. I could work backwards from the DLL path, I guess, but not sure if that will be "future proof".
For the type of app GhostScript is, I would assume they would make this part very easy and obvious, since a lot of programs will be doing exactly this. With all of the free "print to PDF" drivers out there, you would think this info would be easy to find, and maybe it is, but I sure can't find it. Hopefully I'm just missing something, because I don't know where to search, or the right keywords to find it on Google.
I'm tempted to use "GSLite", but so far the only places I've found to download this doesn't have any info on how to download the GS source code for the build of GS they are using, and I think that violates the GS license (not making source code available), so for now I'm just thinking I'll have users install GS themselves, and just look for it -- instead of making it a sub-folder under my app or anything like that.
try ftype (which of course may give acrobat or something, but worth a shot)
maybe some windows expert can tell how to acess the alternate apps list you get by right clicking a ps file...
HKEY_LOCAL_MACHINE\SOFTWARE\Artifex\GPL Ghostscript\9.07
After doing a registry search for a few different keywords, I found the above key which contains a (default) string that points to the install directory. I then did a Google search on that registry key and found some links to the GhostScript source code that sets that value, so I think it is safe to use. I would post those links here, but none of them are good sources (one I had to use Google's "from cache" feature, and the other was just a random person posting a snip-it of GS code). I'm sure it is in the official source code download from their website, if anyone else needs to confirm this, possibly a file named nsisinst.nsi, an install script.
Related
I am trying to find a copy of the program chkmatch. The link everyone points to is http://www.debuginfo.com/tools/chkmatch.html, however this site seem to no longer be up. Does anyone know of a mirror or alternate download location or even an alternative program? I am trying to make a PDB and dll match for debugging purposes.
Welcome to the Internet!
There's Wayback Machine website that helps in such situations
https://web.archive.org/web/20210205095232/https://www.debuginfo.com/tools/chkmatch.html
(And I assume you understand that the DLL and the PDB should be built from the same source with the same options, otherwise it is useless and may give misleading information)
This is likely not a simple topic - I have researched this to the best of my abilities and realize that it is not supported in any typical fashion.
My goal is to enable something similar to .app files from OSX, where the application, as well as its user data, can exist in the same file. I imagine it would require writing a tool to manage this behaviour, but this question is more about how to achieve this in the Windows OS. I am quite flexible regarding the implementation details, but the more straightforward the behaviour, the better (i.e. avoiding copying or compressing/decompressing entire directories/archives at runtime would be ideal).
Approaches I have considered:
Find a way to get explorer to treat a directory as a file, so that it can be associated. I have found a way to get explorer to treat a directory as a control panel item, I have thus far been unable to find a way to use this to associate a custom program. See the infamous "godmode hack" for Windows (name a directory something to the effect of "GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}"). This one seems the most hopeful, but I'm at wits end trying to find information about creating a new association of this type.
Come up with some kind of archive format which can extract executable information to a temporary directory, launch this executable passing the archive as a commandline parameter. This seems like the ugliest solution, from a performance perspective. I would prefer a different solution if at all possible, one which doesn't involve making duplicates of the program or its data to run.
Find a way to associate a directory directly, though I have found no trace of this being supported in Windows, and I assume this is a dead-end.
Find a way to get an executable to include writeable embedded files. I have been unable to make any headway with this- I even tried a resource hacker approach, but obviously you cannot modify the assembly while its in use.
Tried to make a self-modifying JAR file with Java, but the route I took would add the JDK as a runtime requirement, which seems a bit overkill. Even then, it would be limited to Java, and I'm pretty sure it's not actually supposed to allow that in the first place.
Modify Windows Explorer. I shudder at the amount of work this would take, not to mention the at-best gray area it falls under legally. Perhaps there's a way to extend explorer to achieve this, I'm not sure.
A custom archive file. This seems like the most straightforward way to do it. But it would ideally need to be an archive format that has very little overhead for file I/O. Could even be some kind of virtual disk that gets mounted, but I am imagining that would be pretty heavy.
I would appreciate any insight that anyone has on this topic. I won't go into reasons as they are irrelevant to the question itself- I'm aware it is likely not the most practical solution to anything in particular. Consider it a novel pursuit.
It can be done by application virtualization,
Read this wikipedia page theory:
https://en.wikipedia.org/wiki/Portable_application
https://en.wikipedia.org/wiki/Application_virtualization
And two pages about software:
https://en.wikipedia.org/wiki/VMware_ThinApp
https://en.wikipedia.org/wiki/Turbo_(software)
Windows 7 added the ability for a Desktop.ini file to add/change the folder verbs on a per-folder basis. Using that trick it is possible to create a "folders as applications" style setup.
On Microsoft's website about UAC and in several existing answers and articles (like this one) it is mentioned that the Installer Detection of Windows checks the assembly for certain keywords for detecting if the application is an installer or not:
Before a 32 bit process is created, the following attributes are checked to determine whether it is an installer:
Filename includes keywords like "install," "setup," "update," etc.
However, I could not find a full list of those keywords. Only "install," "setup," "update," etc. is mentioned even on Microsoft's website. So what are the "cetera"?
Probably the closest you'll find to a "full list of keywords" is to read the shim database itself at %windir%\AppPatch\sysmain.sdb. (And possibly other .sdb files in the same folder).
The sdb2xml utility seems to do a good job of parsing it. The XML output from the sysmain.sdb on my Windows 7 x64 system can be found here.
A useful starting point would be to search the file for the string "GenericInstaller". You'll find <exe> profiles matching against filenames ("*instal*", "*setup*", "trustedinstaller.exe", etc.), checksums, file version information strings ("InstallShield*", "RTPatch Executable", etc.) and other various attributes. It sometimes even recognises the presence of other files such as "EULA.rtf".
To extract a full list of filename patterns used for installer detection is a bit nontrivial since there seems to be a number of different classifications for installers ("GenericInstaller", "SpecificInstaller", "MozillaFirefoxSetup", etc.). But I'm sure anyone who's read this far will be able to find the information they need by digging around in the XML.
The full list is probably undocumented on purpose and might not be the same on all versions of Windows. It might also include ISVs that Microsoft do not want to shame in public.
As MSDN says, the filename is not the only trigger and I know that NSIS installers are detected based on a byte signature.
The correct way to deal with this is to make sure your installer is Vista/UAC compatible and add a requestedExecutionLevel node to your manifest.
If on the other hand you actually wanted to trigger the detection then I assume you can just add a keyword to your version resource or string table...
I've created a simply toolbox/dashboard in Visual Studio Express in VB for my work that contains links to all of the software and shortcuts we use on a day-to-day basis (see the image below, company name/app names covered to protect the innocent :p)
This was originally created for just me, then I modified the code to work on my co-workers computer. The changes that needed modifying were the addresses for each of the apps. Say, for example, App 1 is directly on the C:\ drive for me, but for my co-worker it is buried in C:\Program Files\blah blah blah. I would have to go in and hard code that path for each and every differing app path, and then if something happens and the path changes, I have to recode it again before deploying it.
What I would like to do it something where the user can modify the path so all I have to do is deploy the executable and the user can modify the path on their own. What would be the best way to accomplish this? Would it be best to have the executable look for a text file to read from/write to? Is there an easier and more effective way to do this? I'm open to any suggestions at this point
If you shellexecute just the program name, it will be looked up in the AppPaths registry key. See HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths. Plus it will open anything. If you want to open a text file a.txt, register it as a.exe. Typing a will run the command (notepad c:\somewhere\a.txt).
My friends are losing points in their computer science classes because their submission graders decompress and read zip files, which are obfuscated by a bunch of Apple metadata crap generated from zipping a file through the right-click contextual menu in Finder.
I've written a bash script to zip only unhidden files from a specific directory, and I've added a contextual menu service through Automator so this script can be run from right clicking a file.
The problem is I don't want to manually copy over all this stuff and make Automations on each computer my friends use. I'd like to leverage make or some similar utility to make an executable that will add the bash file and automator menu service to any computer the executable is opened from.
I'm lightly familiar with make (more familiar with rake), but I can't find out how to package the automator service and install it on their machine through an executable.
You'll want to package your automator application and script(s) into an Installer Package (.pkg). The best way to achieve this is to understand some general concepts, the commands to build one, and by checking out some tutorials or other relevant information.
I recommend for creating your first Installer Package using a utility
such as Packages (open-source and free), which has excellent
documentation, and is less complicated than using the command
line tools. Basically it puts a nice gui around the Apple tools which
are somewhat nonintutive by themselves.
Building Installer Packages is not the easiest thing to do your first time, and it might take a bit of patience to finally get it right. Once you've successfully created one you should have a good grasp on what is involved in putting them together along with the concept behind it all. At the very least, this information hopefully points you in the right direction regarding your question, and/or gives you a better idea of how to accomplish what you want to do.