Add support to retrieve default applications directory

[Larusso]

Description

Add new function application_dir and implement it for windows and mac os. Windows uses FOLDERID_ProgramFiles to retrieve the path. On mac os the path is a hard-coded value /Applications

I don't know if this fits 100% because windows has multiple program files directories from the switch to 64bit. It just fits nicely in my tool :)

[soc]

@Larusso Thanks for the PR! Sadly, I fear that the large semantic differences between different platforms, and even differences between versions of each individual platform, make this a poor candidate for inclusion.

The existing functions are all designed from a "what are the specific usecase that would make developers want to use this function" POV, and I fear the differences are too large in the case of application directories to provide any kind of useful semantic to the user.

I'm closing this, but feel free to comment or reopen, if you feel there are some ideas/insights/... I missed.

[Larusso]

No problem. After opening I also realized that it might not fit 100% as there is also the issue of having potential multiple places for Application and Library directories on mac and Programm Files on windows.
But what I actually needed more in the end was the windows specific unsafe API to fetch the Program Files directory. Do you think it makes sense to pull this part out or give some kind of access through your crate?

I speak of https://github.com/soc/dirs-rs/blob/36b3729aaae528c52f22f2e7e13631f5b41b02d0/src/win.rs#L30-L44

[soc]

I was considering having a more low-level crate for unrelated reasons before ... would you rather have a low-level dirs-sys crate or a crate with a single known-folder function in it?

(To be honest, I found the naming of your fork quite ... unfortunate, especially as the README has not been updated to reflect the changes (or why the crate exists). It's of course fully within your right to pick any free name you want – I guess that I regret not having name-squatted all dirs2, dirs-2, dirs_2, ... variations from 2 to 99 before someone else was able to claim them. ;-D)

[Larusso]

would you rather have a low-level dirs-sys crate or a crate with a single known-folder function in it?

I think I would prefer a dirs-sys crate. But again my current need is more a known-folder function.

To be honest, I found the naming of your fork quite ... unfortunate

This was one of these split second decisions that I regret the moment I pushed the version. I can update the README (had no time at the moment). But you choose such a descriptive name with dirs and directories ... I went like:

But does everybody understand what I am talking about here? If you have shipped a library out into the world, and you do not like the name, tough tootie. You shipped. And if you so desperately dislike it, then make a new namespace. If you have fred/wilma, and you do not like the meaning of wilma, then make fred2/wilma, or fred/wilma2. It is OK to do that. You will find you do not need to do that very often. It is not like you are going to end up with wilma74, or something like that. But even if you did, that is better than breaking programs.

Stuart Halloway - REPL-Driven Development