Why "Program Files" instead of just "Programs"?

Because of their secret slogan "If it moves, patent it©" other OSs are working like this, so Microsoft®©™ had to change it so they could patent it.

Why "Programs" and not "Apps"?

you're almost there
Replace C: with anything that isn't your system drive

>Replace C: with anything that isn't your system drive
Why? My internal SSD is the fastest drive in system.

>Installs a 32 bit OS
>Every 32 bit app goes in c:\Program Files
>Installs a 64 bit OS
>32-bit apps should go in C:\Program Files (x86)
>64 bit apps now in c:\Program Files
>Shit tier apps are 32-bit but hardcoded the path
>It took ten years for these bugs to get worked out

Shit like this is half of why Windows XP x64 was never able to reach mass deployment. Why not just make

> C:\Program Files (x64)

For the new stuff?
>

Because Microsoft made it like that.
blogs.msdn.microsoft.com/oldnewthing/20131119-00/?p=2623

This but with the System32 > SysWOW64 shenanigans too.

Windows XP x64 Edition got dumped on for being a buggy OS but it was 85% 3rd party codemonkey shit not being ready.

Simple things like naming those directories System64 and Program Files (x64) would have insanely softened the blow, what the hell were they thinking?

They did it for shared DLL's. You can't mix bitness.

>shared DLL's.
I thought it was Linux-specific problem.
Doesn't Microsoft have everything needed for the program in its own directory or even in the binary itself? It's all closed-source, so why not?

Due to no sane package management it's a mixed bag of who knows what the fuck.
They don't call it DLL hell for nothing.

But at least it works even after 10 years. Try that on loonix.

>Try that on loonix.
What do you mean? Gimp was not updated for 6 years and still works just fine on any modern distro.
Meanwhile programs for Windows 7 might have problems with Windows 10.

It's fine in italian

Attached: Cattura.png (140x44, 1K)

Because otherwise people would have expected binaries in the directory itself, not buried another another 2-3 more subdirectories.

I'm still using Stepmania 3.95 that was compiled in 2005.

>binaries in the directory itself
Like in Mac OS 10?

Like Macintosh System/MacOS yes.
If they'd called it just 'Programs' the mac users Microsoft were hoping to convert would have gotten confused.

>programs for Windows 7 might have problems with Windows 10

yeah. no.

>yeah. no.
Why not? I know games for XP that don't work on 7 without some serious fuckery. Some barely run. (And most work flawlessly in wine on Linux).

Wait... are you saying that you have single partition for system, programs and data?

Yes.
All the media and torrents are done by a dedicated NAS.
Everything on which I actually operate is on my only internal SSD.

actually true.
Witcher (first one) needed some tinkering to run on windows 10.
Don't know about any other cases though.

I always thought it'd make more sense to just have every program file, its configs, data and stuff in one folder. If there's a library, it should link to said library folder/file, or keep it in its own folder. Instead of AppData, it'd make more sense to have it just in there program folder itself, maybe under a folder with the username.

Windows filesystem has accumulated cruft, but it's not like linux's FS is much better. The equivilent "where's that binary?" in linux is:
>/bin
>/sbin
>/usr/bin
>/usr/sbin
>/usr/local/bin
>/opt

And if you're included %PROGRAMDATA% in the mix, you gotta include stuff like
>/var/
>/lib
>/usr/lib

Attached: 1270470790709.png (379x311, 8K)

the best minimalist distros have only:
/bin
/lib

I actually see value in having /usr/bin just as i see value in windows %APPDATA% binaries for per-user stuff.

It makes perfect sense there though?
bin is binaries, sbin is binaries for superuser, /usr is a symlink to /, only shit tier programs use /opt, etc.

>defending
The state of gnu/loonix

Attached: 1526563184547.jpg (515x355, 173K)

I also have ~/bin which I include in $PATH (that's how you write variables btw, windowsnigger) in my .bashrc, which isnt sourced by non-interactive shells or shells other than bash.

u mad?

on my windows xp I save and install everything on my desktop.

checkmate, stallman

This is probably the only thing that I actually like about macOS. I can't stand how Linux and Windows does binaries and config settings etc. Problem is nothing can be done about it because muh legacy appz.

yeah but XP to 7 is 32-bit to 64-bit

How it's made in macos?

More power to you friend. Btw %ENV% is valid nomenclature for windows env vars due to cmd, not sure wheather you were looking to be superior or didn't realize that, but i actually like linux.

Attached: Screen-Shot-2012-05-24-at-10.54.16-AM.jpg (300x217, 16K)

Porque sua cabeça está cheia de nada, cara.

mac os x 10.0+:

/Applications
/Applications/Utilities
~/Applications
/System/Library (has some binaries)
/bin
/sbin
/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin
/opt
/usr/local/opt
& probably more

Attached: Screen Shot 2018-05-23 at 16.44.01.png (419x618, 100K)

wrong this is what's in bin etc
Applications get installed in applications

Attached: Screen Shot 2018-05-23 at 16.45.06.png (415x612, 71K)

but both list programs

/bin is just for commands

That looks like shortcuts to installed applications not actual filesystem and it doesn't explain anything.
How do you backup config files of single application to external folder?

programmi is comfy as fuck what the heck

WEGETTHISTHREADEVERYWEEK

/opt is Linux's equivalent to PROGRA~1. Programs with most of their stuff, including binaries, data and libraries.

Those are actual .app packages. Usually programs put their configs in ~/Application Support, that's not enforced though.

~/Library/Application Support*

and commands aren't programs?

it's for executables

To make lazy faggot developers handle spaces in filepaths

If you delete one of those is like uninstalling a program on Windows?

>yeah but XP to 7 is 32-bit to 64-bit
>Implying 7 has somehow lost 32-bit support
Yeah, no.

.apps? Yes. Just like installing is simply copying the .app.

So these are just fuckhuge archive files with executables and all files program uses?

The poster you quoted was correct to point it out due to the extra layers/emulation required to keep old 32-bit apps working. To them, the system looks just like it did on XP. This isnt just about filesystem locations changing, you don't seem to realize how fundamental the changes to vista+ were, with new driver model, new security model, etc.

Attached: nicejob.gif (200x100, 8K)

That's the main idea, yes. Some applications think they're special, though, especially applications designed for Windows First, and violate that principle (they'll usually come with installers, too).

They're simply folders, all support files are in there.

Attached: inside.png (657x572, 45K)

They're actually carefully formatted directories that Finder shows as a single file, not an archive.

Attached: Screen Shot 2018-05-23 at 11.26.53 AM.png (697x478, 37K)

So each application could have their own copy of the same dependency?

Does deleting the .app remove all associated configuration/shared libs/logs etc? Seems a bizarre UX that deleting a file triggers the system to clean up other cruft, and if it doesn't then that seems like a glaring oversight.

Attached: huh6.png (382x417, 325K)

Point stands. 32 bit support is present. Some apps for 10 are still 32 bit. Windows shits the bed while trying to run apps that were made for previous versions.

I don't think there are such problems with Linux.

>Windows shits the bed while trying to run apps that were made for previous versions.
lolno

The idea was that you could put the .app back someday and still have it configured, and apple probably didn't want to bother with that. The configs and logs are only a few hundred kilobytes anyway so why not leave them?
Yeah that's by design to avoid version conflicts

>lolno
Elaborate.

It does not delete config files and other "cruft" unless you download the app from the Mac App Store, in which case there is a UX function that will do so for you.
That said, the only places you might have to look in any case for those extraneous items would be in either /Library/Application Support/ or /users/[username]/Library/Application Support/, in both cases being pretty self explanatory.

Absolutely false. Dragging an MacOS app to the bin gets rid of the program, however a shitload of cruft is left behind.

Again, MacOS includes installers or *.pkg files as they are known and function like standard windows install wizards. Goodluck uninstalling them if the developer doesn't include an uninstall pkg file in the dmg :^)

Because a binary file and any relevant assets are just files of the program. Program itself is an abstract thing that does stuff. A file doesn't do stuff until it's loaded into the memory and executed. I guess you could say that a program file being executed is a program. That's how I see it.

Not to mention how many possible config file locations there are:
>Registry
>Program directory
>AppData\Local
>AppData\Roaming
>My Documents
>My Documents\My Games

Not sure what apps youre referring to. 16-bit 9x era apps no longer work sure, but 32-bit XP apps work okay most of the time. Those that don't are almost always an issue with the application, eg the dev make a screwy manifest file or used undocumented apis that didn't carry over.

Fair enough, i'm a bit annoyed by cruft accumulating but it's a problem on every OS. Just surprised they don't give the option of attempting to clean it.

i seriously hope you aren't trying to justify config file locations in linux

>Windows shits the bed while trying to run apps that were made for previous versions.
Backwards compatibility on Windows is and has always been great. Probably the one thing they've gotten right. It is still possible to run programs written for Windows 98.
>I don't think there are such problems with Linux.
Linux the kernel or as a generic name for the various distros? As a kernel they're doing good work keeping APIs stable but still backwards compatibility isn't something they target long term. Moving from the kernel, in GNU/Linux systems backwards compatibility is non-existent, neither are in Android.

In German, it is named "Programme" - I've always wondered about the English name, too.

That's blessedly rare. Most of the stuff that touches /usr/bin and such is open source and for that you use package managers. The exceptions wind up with a bill of materials file in the Library/Receipts folder so you could probably lsbom receipt.bom | rm -f or something. I'm sure there's a program to help you.

Windows has the .msi format which fixes nearly 2 decades of InstallShield wizard fuckery.

This has nothing to do with the filesystem. You don't understand what a filesystem is.

True. I despise windows, but binary compatibility with programs written for ancient OSs has been both their best feature and their curse.

BSD has a series of compatibility layers to run linux binaries going back about as far, thus making it more compatible with linux than linux is.

OS X does like 2 versions and that's it. Architecture changes drop surprisingly early.

>Not sure what apps youre referring to
Let's say "A.I.M" video game. It may launch, but crashes almost immediately in gameplay.
"Hard Truck Apocalypse" will run at something around 5fps.
Some won't even launch, like original Vagners or most games on GOG that use compatibility layers in "version for current OS".

And all the above examples work perfectly in Wine.

>Linux the kernel or as a generic name for the various distros?
The latter.
>GNU/Linux
Even in any other Linux distribution.
>Non existent
Why?

>Windows
>C: partition designated only for system and drivers
>D: partition designated only for programs
>99% programs are portable versions
>All config files are stored in program directories among with executables
>No registry entries
>"Installing"==Unpacking program
>"Uninstalling"==deleting program directory
>Too many video editing programs it's getting confusing - create folder D:\Video\ and move all of them inside it
>Program is not needed at the moment - move it's directory to backup drive
>Program is needed at work - copy it's directory to pendrive and copy to work computer
>Coworkers try to mess with my shit and wanna check my browser history - put my programs in a VeraCrypt container.
>Clean system install - only file associations are gone
>Migration from XP to 7 - as above
>Migration from 7 to 10 - as above
>Migration to new machine - as above

Attached: 13803271244890.jpg (320x320, 18K)

I do things similarly except the drive is D and D:\apps only contains non-installable applications, say mpv or inkscape. All installable applications go to Program Files. That way I know absolutely well what will have to be uninstalled properly on removal and where simple deletion will be enough. Both apps and games are lowercase as well.

This is superior to your system.

Because naming them "Programs" would confuse users who are looking for "icons that start their programs" rather than all the .exes and .dlls residing in the folder intended for program "files"

There's a 3rd party program that helps you to do that. I'm using appcleaner myself. However just put in to your bin is fine though.

>This is superior to your system.
In what way? Lowercase makes no sense, since it's not Linux and I deleted everything properly anyway.

>Even in any other Linux distribution.
The only others are using Busybox useful only for routers and embedded applications and Android that I mentioned.
>Why?
Because everything depends on software developed by others. And with everything I even mean graphics, audio, video all the way down to core libraries. If you try to use old software (three-four years old), you'll get a log of myriad errors. Of course if it is open source and errors are in libraries I guess you can download all its dependencies, statically build it and hope it doesn't depend on other software though you still have an even harder 8~10y barrier because of changes in the kernel.

Typing uppercase involves more keystrokes, so matching all folders to that standard requires more work for no benefit. Additionally if you prepend a date to the name an uppercase letter that would follow would be slightly harder to read as the heights would match more often than with lowercase.
I also try to avoid spaces in my names.

>i don't understand colloquialism
Perhaps you can get government money for your autism?

Attached: docsigh.gif (200x150, 298K)

>The only others are using Busybox
So GNU == coreutils?

>Because everything depends on software developed by others
And in the worst case scenario you can simply recompile it.
That is if for some reason it wouldn't want to work with your present libraries.

Why are you typing directory paths in Windows? It's mouse driven system.

Fair point, i'd forgotten how flakey old directx/directdraw apps can be.

Attached: pain12.jpg (400x420, 15K)

>Why are you typing directory paths in Windows? It's mouse driven system.
Not that guy, but I barely use the mouse on my windows system, and folder navigation is quicker with keyboard regardless of using cmd/powershell or
>win+e,ctrl+l

Attached: gimpepe.jpg (1900x2660, 224K)

this is my secret plan

They call it DLL hell because no one has any idea of what ".so" even is, because nobody uses Loonix.

>Why are you typing directory paths in Windows? It's mouse driven system.
I don't think what I'm doing has any relation to directory navigation, aside from not trying to use spaces which is actually useful as I don't have to type in quotes in the command line.
You can also navigate folders using the explorer and a keyboard by punching in names and hitting enter. No need for autocompletion either as would be on the command line and I see more context. With concise naming a folder usually can be selected in two keystrokes provided the first two letters form a unique part among others. In big folders, say \windows this navigation can help you skip to files you know by name without having to scroll and read whatever's in between.

>Windows
>pointlessly uses two partitions
>portable versions; i.e. downloads updated manually
>config files stored in program directories
>cares about organization of said directories
>keeps backup drive of programs
>encrypts entire program directory, not just data
>can't even keep system clean and actually has to ever reinstall
>doesn't know he can backup file associations
>probably doesn't know he can backup HKEY_CURRENT_USER\ registry tree
>moves to new machine and reinstall instead of cloning old system
Were you trying to follow all bad habits?

>Doesn't Microsoft have everything needed for the program in its own directory or even in the binary itself? It's all closed-source, so why not?
Most Windows system APIs are not standardized or public and applications need to use the system's meticulously versioned DLLs to invoke them safely.
The legacy clusterfuck of a system presented through these doesn't seem to have much to do with the actual OS kernel these days.

>Gimp was not updated for 6 years
It may look like that but Gimp actually gets at least one monthly update.