I have written a C++ library which will be used for POS applications,
Library are to be distributed as binaries(DLL only for windows) to customers
I have understood that library can be used in 3 ways on client machine
By placing binaries in the directory/folder of application executable
By copying binaries to system32 directory
By adding path of the binaries on client machine to PATH environment variable
Kindly educate me if there is a better way of installing library on the client machine,
Which is the best way to install the distributed binaries on the client machine?
Thanks in advance
I strongly recommend you, to put the library into the application folder: Putting it into system32 is an invitation to DLL hell: A newer version in the app directory would be overruled by an older version in system32.
There is quite an easy rule:
if the library is intended for a special application, store it with the app
if the library is intended for general consumption, store it in system32
I always bind the dll's in my application. Its the safest approach i know.
Related
According to the Windows installation rules, programs should be installed to
C:\Program Files (64-bit program / x86-64) or C:\Program Files (x86) (32-bit program / x86). The program is copied into a sub-sub-folder containing the vendor name and the program name.
But why doesn't Chocolatey install packages into C:\Program Files\<Vendor>\<Program>\?
10. Apps must install to the correct folders by default
Users should have a consistent and secure experience with the default installation location of files, while maintaining the option to install an app in the location of their choice. It is also necessary to store app data in the correct location to allow several people to use the same computer without corrupting or overwriting each other's data and settings. Windows provides specific locations in the file system to store programs and software components, shared app data, and app data specific to a user
10.1 Your app must be installed in the Program Files folder by default
For native 32-bit and 64-bit apps in %ProgramFiles%, and %ProgramFiles(x86)% for 32-bit apps running on x64. User data or app data must never be stored in this location because of the security permissions configured for this folder.
Source: Certification requirements for Windows desktop apps
Version: 10 (July 29, 2015)
It depends on your version of Chocolatey, it's settings and the packages themselves.
To start, see Tools vs Applications and Chocolatey's distinction (
https://github.com/chocolatey/chocolatey/wiki/ChocolateyFAQs at the
bottom).
If the package does not use a native installer (a tool), it depends on
if the package author has used the bin_root concept that is up and
coming in a future version.
For example, SysInternals will go to c:/sysinternals right now unless
you have a defined $env:chocolatey_bin_root variable. The concept in
the code will change as well as right now this requires it to be a
subfolder of the system drive and I don't see us developing the final
feature with that limitation.
If the package doesn't have that concept yet, one can always ask the
package author to incorporate it.
If the package uses a native installer (an application), one can use
installArgs to pass arguments to the native installer
(https://github.com/chocolatey/chocolatey/wiki/CommandsInstall) and
tell it the directory to install the application to. This does require
you to know what you need to pass to the native installer. If you want
your applications in a custom directory, there is an assumption that
you are already an advanced user so it is expected that you would know
what to pass the installer if you were doing a silent install.
Slightly paraphrased from: https://groups.google.com/forum/#!msg/chocolatey/uucAz8GxebA/HEPAKp69d90J
Also,
NOTICE: As of 0.9.8.24, Chocolatey's default install location is
C:\ProgramData\Chocolatey
This reduces the attack surface on a local installation of chocolatey
and limits who can make changes to the directory.
Source: https://github.com/chocolatey/chocolatey/wiki/DefaultChocolateyInstallReasoning
And from personal experience I can attest that that concept is an excellent line of defense (when properly configured, used and understood).
PS:
As you already added to your answer, technically the requirement is %ProgramFiles% and %ProgramFiles(x86)% environment variable(s where applicable).
For example, %ProgramFiles(x86)% could as well point to P:\Software\Programs\x86\ (instead of C:\Program Files (x86)\).
There is obviously a lot of legacy software (now (re-)packaged) that never used a <vendor> section in the path-name.
Hope this helps!
i was try to beginning ruby/jruby desktop application development, as i've googled before, ruby lacks of distribution/deployment system, so i haven't decided which one to use, is it ruby with green_shoes (gtk) or JRuby with purple_shoes (swing), if i go with green_shoes, then i should provide GTK Runtime, and if JRuby then i should provide JRE, or maybe if possible a portable internet browser and portable server (just like PHP's UniServer).
is there any other alternative to overcome this, so that i could distribute my program, ruby with all required dependency for my program only by copying the folder in such portable way?
so if i/they want to use it on windows, i only need to create a shortcut to the my program on the copied folder,
and when i/they want to use it on linux, i only need to "ln -s" to $PATH to that my program on the copied folder
for JRuby only:
GUI toolkit, we can use Monkeybars https://github.com/monkeybars/monkeybars-core
Deployment we can use rawr http://rawr.rubyforge.org/
answers from: Moh Hasbi Assidiqi
Some cross-platform packages like Ruby or Qt prefer %HOMEDRIVE% as the default installation path, Google Chrome uses something in %HOMEPATH%. What's the advantage and disadvantage of each choice? What's the best choice for a simple private application (i.e. a game, where the installation should work without administrator rights)? On the other end: What would be the best choice for an industrial application (i.e. a software that controls an industrial device, running on a computer that merely exists for that purpose)?
If you want to ensure your app can be installed without Admin privs, install under %LOCALAPPDATA% - if you want to install system-wide, use %ProgramFiles%. Whatever you do, don't use %ProgramFiles(x86)%.
As a general rule I find it hard to believe that a single installation will work for multiple operating systems. From my understanding it seems that you would need multiple different installation files to handle each of the different file systems (not just installation directory, but the actual file system). This will span not just private, and industrial systems, but all business systems as well. Go to the download page for any software that is available for multiple OS and they will have a link for each one.
A colleague of mine agreed to using Subversion (SVN) for our little project, but only if he doesn't have to install it. He has a U3 USB stick where he keeps the project files and he would like the SVN client to live there as well. I tried searching for a non-installable SVN client, but couldn't find anything (although I suspect that many of the available clients would run if just copy-pasted from an installation folder). What can be recommended?
I'd really like to get version control going. It would be best if it had a GUI for merging files too, not just the command line.
Added: The copy-paste from an existing installation is one solution, but I'd like to see first if there perhaps isn't some client that does not require installation by design. If not, I guess RapidSVN is nice enough (although it does leave stuff in Windows registry).
Try RapidSVN. The CollabNet binaries can be used in a similar fashion for command-line support. Yes, these have installers, but you can simply copy the binaries around -- I use Universal Extractor to get the binaries out without having to run the installer.
Also, an enterprising user has packaged RapidSVN as a PortableApp. There is an "installer", but it really just unzips things into a directory of your choice and writes a default configuration file into that directory.
Try Alagazam.net's Subversion Windows Installer. There is also a version with just the binaries without an installer.
I'd go with the copy and paste the bin folder from SlikSVN.
It seems like SlikSVN is the underlying platform behind several graphical SVN clients. In my experience it seems stable and reliable.
Specifically, the bottom link on this page seems to be a non-install/xcopy precompiled package (although I haven't tried this one myself, only inspected it). It does not appear to be the newest, though. You might do your friend a favour by installing the newest SlikSVN on your own computer, and then share the bin files with your codeveloper.
If Java is available on the machines you could use SVNKit.
There's a portable version of SmartSVN which is what I use. It's a pretty good SVN client, but it needs JRE. It has a nice GUI and all.
There is a portable version of RapidSVN here. Just install it to a flash drive.
I was able to use the command line client that I had installed onto a USB stick. I then whipped up a couple batch files that did the basic checkout, checkin stuff, and one batch file that gave me a command prompt with a PATH set.
It doesn't have all the integration of something like TortoiseSVN, but I don't think you would be able to easily do that from a USB stick.
I've had this same problem, and thought it would be easier to find than it is. Bert Huijben posted the solution as a reply to Cecil, but his link was outdated.
http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=8100
Scroll to the bottom where you can grab a ZIP file of the binaries. It works for me.
Alternative two should be pretty sufficient. But both methods requires installing it to the USB device which I guess is similar to just copying onto it. I checked Wikipedia and there are some standalone listed there.
SmartSVN, QSvn (portable version requires install), and Syncro SVN Client (they have versions which requires you to extract and run), etc. But does it copy, and does it run any different than installing to the USB?
Alternative One
Load Cygwin on the USB device, install SVN support and run it off of that. There isn’t any up (which I assume is more than possible) since I've had the luxury of using TortoiseSVN (requires install).
Alternative Two
Install TortoiseSVN on a USB device and use if off of that. It has a GUI interface for merging and diff. This may be relevant to your interest. However, Google has some results indicting they are slow.
Finally, there is an PortableApps version of RapidSVN:
Another alternative which may be acceptable to some users:
The Eclipse IDE is portable (not entirely; it depends on Java). Use the Eclipse SVN plugin (Subversive or Subclipse). This takes care of the daily needs.
You may choose to point to a Java Portable installation to make it truly portable. However, I believe it might be slow to run off a USB pen drive.
What would be the negative effects of installing a legacy 32bit app into the C:\Program Files instead of the C:\Program Files(x86) ?
It could cause a problem based on what your application does.
For example, if your app queries for the Program Files folder, the WOW emulation layer will return Program Files (x86). Thus if you're trying to find things relative to where you're installed, you'll fail.
I don't think it matters. You can run a 64-bit from your Desktop, an external drive, etc. the same way you can run a 32-bit app. I think the difference is purely for organization.
Or say you are developing a 32-bit and a 64-bit version of an application, you could install both of them and run them side by side by putting them in the separate Program Files folders.
None. I believe the two folders are there for organizational purposes only.
None whatsoever. I do it all the time, and have never encountered any ill effects. I believe it's purely organizational.
Probably none if the application that you want to install doesn't have a 64 bit parallel version.
If it has and you decide to install it, by default (if it is using the same folder names) it will overwrite the existing 32 bit application.