|
An application folder containing the exe and everything needed to run it. This is encapsulation and makes for good engineering.
Why have we abandoned this model?
Because it leaves very easy to copy an application and use it without paying for it.
So along came the Windows Registry, Program Files etc. so vendors can stick bits and bobs in multiple obscure and hidden corners and make sure the app will not run if they are not all in the right places with the right values. It is protection of property by obfuscation. The Windows App Store takes this a step further, denying you knowledge of even where the app is stored on your machine. This is madness and makes a big mess on your machine.
Monetisation security should be done properly using encryption instead of obfuscation. Go back to encapsulation in one folder but within that folder put some encryption keys that have to be set up online by the vendor using your device id.
|
|
|
|
|
I still like to build my own little computers for which there is not much out there to download. So, let's not forget the way this used to be done. 
Also, don't take the 'compile' part too literally. I might also write machine code directly or perhaps assembly.
Edit: Too bad you can't use the usual tags in the header, but I will leave it that way.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
modified 4-Feb-22 10:11am.
|
|
|
|
|
Or as I did in my summer job the year before I started my studies:
Flip 16 switches, press deposit, flip 16 switches, press deposit, ...
True enough: On the average, 8 of the switches were already in the right position. And all I had to program by flipping switches and pressing deposit was a very minimalistic bootstrap for the tape reader. If my memory is correct (this was in 1978), the bootstrap was around 20 instructions. Its only purpose was to read in a full size bootstrap, maybe a meter or two of "paper" tape (because it was read for each new program load, it was not paper but aluminum with a plastic coating, to stand the wear), capable of reading in the paper tape reel with the full application program).
I also programmed by flipping/deposit when we did a student exercise in microprogramming an AMD 2901 four-bit bit slice processor. (Youngsters may have to look up the terms in an old tech dictionary ).
I do not miss programming at that level, though.
Nor did I ever care for problem solving on Turing machines. They may look great, though: Mechanical Turing Machine in Wood[^]
(The "classical" YouTube Turing machine is the 2009 vintage LEGO Turing Machine[^], but it doesn't look as great.)
|
|
|
|
|
I have handled a number of Windows installers that appears as a standard .msi installer - but then they install in "incorrect" locations (e.g. 32-bit versions in 'Program Files', or 64 bit versions in 'Program Files (x86)').
Rather than storing user preferences in HKCU, they put it in some file - maybe in some strange directory - named e.g. '.conf' or .<application_name>.
Installers defining a bunch of environment symbols, rather than putting it into the registry (and, obviously, the code depending on them).
Installers that are not self-contained, but take for granted that other subsystems are installed; if they are not, the installation just fails.
Installers that suggest an installation location but allow you to modify it - but fail if you specify e.g. 'C:\Program Files': Installation procedures (and of course, the system to be installed) cannot handle paths containing a space.
Installers that have completely new ideas about where to place the code & resources for each new major version, so they are unable to update an existing version.
Installers with uninstallers that leave a lot of garbage spread all over the system (including the registry, environment symbols and C:\users\...) after you uninstall the system.
I have even seen Windows installers running bash scripts assuming that environment symbols are case sensitive, failing to find already defined symbols because the existing casing didn't match what the bash script expected.
Needless to say, 99,9% of such cases occur with systems ported from some other OS. 80% comes from the free, open source community. The only problem I have seen repeatedly in commercial products is the inability to handle paths containing spaces - but we are of course talking about products available for some other OS as well. (To make it clear: I am talking about commercial software obtained the last five years - not something from the DOS days.)
I have seen so many rotten installers and install scripts that the kind of wrapping really doesn't matter much. If the installer writer (and the system being installed) ignores established conventions, that is what makes me stall. Not their choice of installation method.
|
|
|
|
|
trønderen wrote: Rather than storing user preferences in HKCU, they put it in some file - maybe in some strange directory - named e.g. '.conf' or .<application_name>.
10 times better, honestly. Easily backuppable and portable. Windows registry is an error.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
So, you propose to live by the general rule: If there is something I know another way of doing, which in my opinion is better, maybe ten times better, then I will disregard any conventions, recommendations and standards!
That's how we create chaos.
And, I must emphasize: One major factor, maybe The major factor leading to the breakthrough of Windows in the 1980s and 90s was that they very strongly pushed (almost mandated) strict adherence to strict user interface guidelines. If you knew how to handle one Windows GUI application, you knew how to handle them all. Well, not quite, but the Common User Access specs (originally from IBM) was what killed the market for user manuals.
As a parallel: What killed the biggest competitor on the desktop was the explicitly pronounced philosophy: "Mechanisms, not policies". The libraries and UI subsystems should in no way restrict the developer's freedom to say "I did it my way!" Seen from a user, running a number of GUI applications from different sources, user interfaces was a mess. Windows was so much easier, where you did similar operations in very much the same way in different applications. It took something like fifteen to twenty years for the majority of developers that making users "feel at home" is fundamental to user acceptance. But it was too late. And a fair share of developers haven't learned the lesson yet.
As a developer, you must be willing to learn how to do it. And you must learn how to take backup of a branch in the registry. At the same time, you should learn to make a simple translator for rewriting that registry backup to a format recognizable in an OS environment who like to do it their way, with no intent of learning how it is done under Windows. Make sure that the translator can generate files in XML and JSON and YAML and 7-bit ASCII with bracketed sections, in "=<value>" format or " <value>" format, a tree either flattened by concatenating the path with some character, or by a nesting mechanisms (not available in all formats), with numerics and other scalars coded as hex digits, symbolic names (for enum types), decimal digits, or possibly b64, similar to other binary data, and text values coded as UTF8 or 7-bit ASCII with backslash escapes for non-ASCII characters, or HTML character entities by name, or HTML style # escapes, or...
Remember that any system, any developer, is free to say "I did it my way". Each and every one of the config file format variations is ten times better than the registry. And don't forget that famous Tanenbaum quote: "The good thing about standards is that you have so many to choose from. And if you don't like any of this year's crop, just wait until next year, and you will have a handful more to choose from". (Quoted from memory - I can look up the exact wording if needed.)
While you sit coding the parser for config format #42 (or try to make some parser code work, something you found on internet), the Windows guys will continue to do it in that one way that they agreed upon.
|
|
|
|
|
@den2k88 correct. registry is a big misconception.
today most software uses the %localappdata% or your userprofile to store config data because it is easier to maintain and rollout.
|
|
|
|
|
Android: app store
Windows: direct installer
Games: Steam (epic if need be)
Switch: buy physical
PS4: trying to lean to physical, but most are downloads
movies: streamed where possible, rent or buy dont care take my money. I want to give money to someone to watch movie but sometimes they just make it hard for no benefit (except ogirinal owner contract bs stating how it distributed) and I dont want DVD clutter sooooo 
|
|
|
|
|
Option 1 should be expressed as two separate options:
1A: Download a web installer that only downloads and installs required features
1B: Download an offline installer that includes all possible options in a single package
I need option 1B often, because many of our target machines do not have an Internet connection (yes, Virginia this is A Thing).
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: 1B: Download an offline installer that includes all possible options in a single package
This! Absolutely! We have many non-Internet connected networks and trying to install software on them is a pain in the neck. What is even worse is when the software needs to be registered/unlocked using an Internet-generated file. For example, we use RedGate SQL tools and the only way to unlock them on our network is to generate an unlock request from the software, manually type it into the registration website, get the unlock file, sneaker-net it over to the closed network, then upload into the software. 
|
|
|
|
|
There is a variation of 1 (both in A and B variants) that I detest: Where you can not click once, and installation runs ahead to completion, but rather presents an "endless" series of buttons you have to click without requesting any more information:
"Do you want to install NewSystem?" Well, why do you think I started the installer?
"Begin configuration". So show me the configuration screen, then!
"Ready to start installation". Why do I first have to complete the last configuration screen, and then yet another screen to confirm that I know it was the last configuration screen?
"Installation complete", and then
"Saving preferences?", then
"Cleaning up" and finally
"Exit the installer" - can't you even do that on your own, without another button click??
Some installers are really bad at asking for one single piece of data, running for two minutes before asking for the next piece - usually a confirmation that the default is perfectly fine - running for two minutes more, and the procedure is repeated ... Some installers require you to babysit it for half an hour! In the old days, the installer for Windows itself was a bad case of this (probably a carry over from the days when Windows were delivered on 42 floppies, so you had to sit through it anyway, to switch floppies!), but they did clean it up, I believe it was for XP.
|
|
|
|
|
I write the installers for our products, and they present as few choices as possible. No group selection, no install folder, etc. Most of the the time it starts up, you click the Install button, and you're good to go.
We have to encapsulate several third-party installers, which I try to run silently. Those that don't are a PITA. I used to try sending messages to the applications to click buttons for the user, but Windows 10 doesn't seem to allow that any longer.
Software Zen: delete this;
|
|
|
|
|
Portable Version preferred, but keeping it up to date can be more difficult.
|
|
|
|
|
Which is the precise reason I love them. You can freeze in time the desired behavior without switching to the new and improved randomly changed version.
Also the whole package is always in your possession, easily backuppable and not relying on external components for the installation.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Quote: Download the binary directly and move it into place
Would be mine. These tend to be "Penguin Droppings" that I contain in "C:\ProgramFails\whatever\" along with almost as half-![Elephant | [mastadon]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/elephant.gif) ed ports that attempt to install into "C:\SelfDeclaredCrapware\"; on the assumption that they're likely to be so badly ported that they'll break when forced to confront Windows default permissions in Program Files; and probably also barf over a space in the path.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
Dan Neely wrote: almost as half-a--ed ports that attempt to install into "C:\SelfDeclaredCrapware\"; on the assumption that they're likely to be so badly ported that they'll break when forced to confront Windows default permissions
How many of you have a "C:\Intel" folder? Does that qualify as "SelfDeclaredCrapware"?
|
|
|
|
|
Depends on situation
1. need something like redis etc I would prefer Docker
2. framework to add to a project etc yarn, npm, nuget, brew etc
3. just need another tool I would prefer a install wizard to take most of the effort away from me 
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
|
...Would you not prefer a one/few-click(s) solution? 
I always imagine the people who prefer CLI tools or a manual build or some such brag about it to score nerd-points with their nerd friends and are generally disliked by the rest of society.
I knew a guy who prefers working with a CLI and he was a good friend and a nice guy, but when we found out we were all like "but he's such a nice guy" and "we didn't really notice anything odd about him" (of course he was still found guilty for being an incredible nerd).
Yeah, these people could be anyone, could be your neighbor, your children, your significant other or your dog.
No one is safe.
|
|
|
|
|
When presented with the "Custom" option in an installer I always select it. The reason for this is I want to know what the installation options are, even if I don't change them.
|
|
|
|
|
Yeah, me too, but that's still not even close to using a CLI.
|
|
|
|
|
I think obermd only meant to refer to the one/few click part. Make it as simple as possible, but no simpler. obermd don't want it so simple that you don't know what is going on.
I tend to agree, with one exception: I don't want that "Custom" or "Configure" button, but a screen telling: These are the default options - edit them as desired before clicking 'Install'. If possible, the editing should be directly accessible as pulldown lists, edit fields, spinners etc., at least for the most commonly changed options. If configuration is so complex that it takes multiple screens, they should have buttons for "Configure <xxx>", "Configure <yyy>" and "Install".
I view CLI as a tribal language, a way to distinguish between "us" (mastering it) and "them" (not mastering it). A tool for exercising power and promote your own rank. The programming world is full of such tribal "secrets" - I think that two thirds of the C# language 'enhancements' for the last three or four latest language versions essentially is providing tools for us who master the 'advanced' language aspects, to elevate us above those lower programmers who is not at our level. This certainly is not particular to C# - most evolving languages end up like that.
You see it everywhere. If you don't master all the darkest corners of Git, you are a worthless newbie. If you can't tell the difference between all the 14 ways to create an object. If you have to ask the meaning of an abbreviation. And so on. So much of the ever changing set of languages, frameworks, protocols, standards, ... serves no other function than keeping us ahead in the rat race for staying in power. If things stabilized, so that everyone could learn the tools, then we would loose power.
CLI is used to stay in power by focusing on something those inferiors want to learn; that makes it easier. Like, I don't care to learn how to shoe a horse. So those promoting riding, rather than biking, walking or driving a car, will stand above me, wherever he manage to push horse riding as The Right Solution. CLI is similar to that.
|
|
|
|
|
CLI is made to make stuff automatable. Your sysadmin that manages 300 devices can care less about tribalism, he wants to install / do stuff on all the devices with one operationa and fix the ones that fail (ideally none).
GIT CLI is horrible for everyday use, but to automate build procedures it's pure gold.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Numerous times I have met this "You need CLI for automation" by pointing to the numerous systems that configure and manage automated jobs through a GUI.
I haven't seen for years any reasonably modern backup system having a CLI as its primary interface for configuration, management and monitoring. All automated build systems I ever worked with are managed through a GUI. Managing regular tasks in network components: Setup, scheduling etc. all goes through a GUI. Software deployment in a local network: You set it up through a GUI. The list goes on and on.
The CLI guy hesitates: "Well, of course you could do it that way, but...". The unpronounced statement following "but..." usually is a variation on "but I never cared to learn how to set up a GUI for such tasks, because I am a CLI man!!
|
|
|
|
|
|
Bigger things, like Visual Studio (Code), intteliJ and so, that contain many modules, interact with the GAC or otherwise with the system (logitech/steelseries keyboard/mouse engines), an installer with, silent or not, auto-update function is the way to go.
Small things, like WinSCP, WinMerge, Audacity, virtualdub, and in general those "little helper tools" i prefer as portables, a zip that I unpack to my tools folder, set a path (if it makes sense) and then they reside in their folder, can be taken on a stick with me, without worrying about almost anything.
They are replicated from PC to PC and are just... there.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
