LG webOS SDK
-
-
Generic "files" would have probably been a better word.
Everything in the filesystem is a "file", including stuff like the aforementioned
NTUSER.DAT. So, no, that is not a better word.Yeah... Unfortunately that gets annoying when you have something that meets both or neither of those categories.
What possible thing could that be? And why do you need to write it to disk at all?
I think that's the main reason people put stuff in the Users\name folder
The main reason from my experience is lazy/incompetent Linux programmers assuming Windows is Linux.
-
The main reason from my experience is lazy/incompetent Linux programmers assuming Windows is Linux.
-
...
Never mind.
Annnywaayysss...
Yeah, writing to
/home/is quite the WTF. Did someone accidentally a variable somewhere and intend to write to/home/username?If only they accidentally
$HOME...How would they get into the proper home directory even using variables if they require root?
$SUDO_USER? That relies not only onsudobeing present, but on installer running usingsudoas well. It would still break if Isutorootfirst and then run it like that.
-
@sloosecannon said:
...
Never mind.
Annnywaayysss...
Yeah, writing to
/home/is quite the WTF. Did someone accidentally a variable somewhere and intend to write to/home/username?If only they accidentally
$HOME...How would they get into the proper home directory even using variables if they require root?
SUDO_USER? That relies not only onsudobeing present, but on installer running usingsudoas well. It would still break if Isutorootfirst and then run it like that.Oh, so they...
What?
Why wou...
-
Exactly. The only proper course of action, if you install that shit as root, is using
/etcand creating per-user configuration in$HOME/.config/or wherever once it's started by a user.
-
Exactly. The only proper course of action, if you install that shit as root, is using
/etcand creating per-user configuration in$HOME/.config/or wherever once it's started by a user.Yeah, cause that's kinda what
/etcexists for...Sheeeeesh.
Maybe they think their program deserves its own user account. With a name of
.lgsdkTvregistery.
-
Also, did @eldelshell @accalia or did LG's SDK @accalia? I really hope the latter
@sloosecannon said:lgsdkTvregistery
-
That's a ridiculous setup and you (should) know it
He does, and did.
Just like it's not Microsoft's responsibility if people do stupid things with their OS, it's not the application's fault if a program doesn't work on some whackball setup that no sane sysadmin would create
If his applications followed Microsoft's rules/guidelines about discovering file locations, it WOULD HAVE WORKED even in that weird-ass situation.
-
she's
Nothing personal there, just typing too fast.
Windows 8.1 btw :P
Did you upgrade from XP? Is that why you've still got a c:\documents and settings?
-
Oops.
Well, it's mainly the same text, except for the examples, so it's not a huge deal. But seeing obsolete directory names was a bit jarring (and if MS added any new variables after the URL you linked came out, they wouldn't be there.)
-
Unfortunately that gets annoying when you have something that meets both or neither of those categories.
I suspect, given a bit of thought, you could find a preferred location for nearly all files. Word docs, spreadsheets, game save files, source code, etc., are all "Documents". Browser cache, I would semi-arbitrarily call 'not a "document"'.
This can easily mean any complex program has files in both places, and it's understandable why users, especially power users, don't like that, but it's what you're supposed to do. Failure to follow those rules leads to weird shit like the virtualized Program Files subdirectories caused by (for example) old games like Civ III, or your program just not working.
-
Nothing personal there, just typing too fast.
It's an easy mistake to make ;)
@FrostCat said:Did you upgrade from XP? Is that why you've still got a c:\documents and settings?
When I upgrade to a new version of Windows, I always do a clean install. Mainly so I'm not left with a load of cruft from the old OS.
-
Everything in the filesystem is a "file", including stuff like the aforementioned NTUSER.DAT. So, no, that is not a better word.
I claim it's an improvement because it encompasses more things than "Documents" do. I am not saying it's a perfect word.
Don't make the perfect the enemy of the good.
What possible thing could that be? And why do you need to write it to disk at all?
Possibly, compiler intermediate files, although I would be tempted, because of that, to arbitrarily call them "Documents" vs "Program Data". Having half your VS project be under c:\users and half under c:\programdata would be weird.
-
Browser cache, I would semi-arbitrarily call 'not a "document"'.
Cache of any type isn't a document.
And it belongs in the non-roaming App Data folder. Or temp, possibly, depending on how "cache-y" it is. (Do the files stick around for a month, or for an hour?)
Please do not put cache files in Roaming App Data, Firefox did that for ages, it is a bug, and it makes your product almost completely useless for users who have Roaming Profiles turned on.
This can easily mean any complex program has files in both places,
Why is that an issue?
and it's understandable why users, especially power users, don't like that, but it's what you're supposed to do.
... why would anybody not like that?
Are there reasons for any of these assertions?
Possibly, compiler intermediate files, although I would be tempted, because of that, to arbitrarily call them "Documents" vs "Program Data".
Temp, obviously.
If they stick around a long time, perhaps non-roaming App Data.
Having half your VS project be under c:\users and half under c:\programdata would be weird.
Why would anything be under C:\programdata? Where did that come from?
-
When I upgrade to a new version of Windows, I always do a clean install.
You got some problems in that sentence. I have called out the areas of concern.
YKUTW. IDNTIMWYTIM.
-
The real beef I have is people writing software for Windows who do not know how Windows works.
So you've changed your mind about everyone who wants to being able to program?
-
Why would anything be under C:\programdata? Where did that come from?
Well I've got a good deal of stuff there, some of which is Microsoft stuff. What's the intent of ProgramData?
-
-
-
So.... a non-elevated Program Files?
-
If his applications followed Microsoft's rules/guidelines about discovering file locations, it WOULD HAVE WORKED even in that weird-ass situation.
I think @sloosecannon was more addressing even crazier setups (like the time I tried to move the entire Documents and Settings tree onto a different drive on an XP box, live, and then use a mountpoint to redirect C:\Documents and Settings to D:...)
I wonder what SUBST and JOIN could do to break this, as well...
-
Yeah, moving the users folder live is ALWAYS a BAD IDEA
-
Why is that an issue?
Because it upsets people who want to see all their files in one place, is all.
... why would anybody not like that?
Are there reasons for any of these assertions?
Because they feel it's not neat and tidy, I guess? I've seen people bitching since XP or so, maybe even back to Win95, because they didn't like where Microsoft wants you to put stuff.
"It's MY computer and I'll put all my games in c:\games if I want to!" I've seen a ton of that. I'm not saying it's rational, I'm saying it's how (a lot of) people feel.
Temp, obviously.
Well, you'd think, probably. But VS puts 'em in your project folder, so they go wherever your project folder happens to be, which it defaults to being under Documents.
Why would anything be under C:\programdata? Where did that come from?
That's where Chrome (used to) put itself. As far as I can tell, Google did that so they could put the cache under the main Chrome directory, and not worry about "non-administrators can't write to files under Program Files". The reasoning seems to be exactly what I mentioned above: "We want all our files in one place, including cache. Oh, but we can't do that and put 'em in Program Files, so we'll put 'em somewhere else". Since I just installed Chrome yesterday on a brand new PC at work, I can look, and I see they've split it out better--the application is under Program Files and the cache et al are under local appdata.
Wizard 101 and Pirate 101, IIRC, install the entire game into c:\programdata\kingsisle, too, for probably the same reason.
-
-
Google did that so they could put the cache under the main Chrome directory,
AFAIK it was because they wanted non admins to be able to update the browser. And allegedly because then non admins could install the program (tho I don't se how that's a barrier)
-
Ok, I don't know if this was ever mentioned and stuff but ...
How does
My.Settingstie into the whole Windows special folders paradigm?
-
How does
My.Settingstie into the whole Windows special folders paradigm?
You just tell it what settings you want to store, and it does the legwork of putting them in the right place for you ;)
-
@aliceif said:
How does
My.Settingstie into the whole Windows special folders paradigm?
You just tell it what settings you want to store, and it does the legwork of putting them in the right place for you ;)I don't know which one of you added that URL but you broke the tracker... again...
-
AFAIK it was because they wanted non admins to be able to update the browser. And allegedly because then non admins could install the program
I suspect all those reasons apply.
non admins could install the program (tho I don't se how that's a barrier)
Program Files isn't writable to non-admins. That means you have to not only elevate every time Chrome auto-updates, which kind of takes the auto out of it, but also, probably every time you run it, because of the cache and so on being in the same directory structure. (Altho now that I think of it, folder virtualization or whatever the term is probably would've come into play: the cache winds up in something like c:\users\frostcat\appdata\local\low_integrity\program files\chrome...\cache or something.)
-
You just tell it what settings you want to store, and it does the legwork of putting them in the right place for you
I wasn't asking for a zero-content post.
-
I'm not sure what you were asking then?
My.Settingsis an object that does all the worrying about special folders so you don't have to; not sure what else there is…
-
@swayde said:
non admins could install the program (tho I don't se how that's a barrier)
Program Files isn't writable to non-admins
Yeah, but why not install in %APPDATA% or %userprofile% /chrome? That'd have the same effect, except it's now per user?
-
Yeah, but why not install in %APPDATA% or %userprofile% /chrome?
I'm not the person to ask. If I were in charge I would've split it the Windows-recommended way, which they seem to have done at some relatively-recent point.
-
FOLDERID_UserProgramFiles?
-
The main reason from my experience is lazy/incompetent Windows programmers
FTFYLinux and POSIXy developers usually try to get this right, because if they don't, it simply does not work at all under POSIX - the access rights are enforced.
Yes, some misunderstand what should go where but they try.Windows developers generally don't give a shit, especially if they started developing in XP or older, where the access rights were not enforced (or didn't even exist, because Windows will tend to clean up their mess.
-
Also, did @eldelshell @accalia or did LG's SDK @accalia? I really hope the latter
@sloosecannon said:lgsdkTvregistery
Somebody on github posted a stacktrace with the exact same spellar mistake but for
/Users/.lgsdkTvregisteryon Mac OS X: https://gist.github.com/soapdog/620a580f11a8a5453bcbWe have a winner!
Unless that's also from @eldelshell.
-
That's a lie.
You've used the same API call to find the path since Windows 95.
The only change Microsoft's ever made is the addition of the non-roaming version of Application Data. And that was done in like Windows 2000, or possibly even NT4. It's not a recent change. And it's a non-breaking additive change.
OK, I've missed the fireworks, but I want to address this.
Sure, if you're looking just at basic folders, a Win95 app that used proper system calls will install fine on Windows 8.
But then there's all this other shit:
Let's start with the "where should apps keep their shit" issue. "Documents" was mentioned as the proper place. A terrible idea, but fine.
Looking through my own
Documentsfolder, it's a mess. Some apps create a proper subfolder with their full name. Others use strange abbreviations, or linux-like dot prefixes. Some create a company folder tree and organize their stuff there. I see a few that just dump whatever file they need directly inside "Documents". And then, there's stuff likeMy Games, which has the same sort of mess repeated inside it. And mixed with all this crap are my own documents and work items. Which are one name collision away from some installer deciding to "clean up" before proceeding. Who the fuck thought that was a good idea?Then there's the hidden AppData folder. The same chaos there, except at least my documents aren't in the mix, so it's a bit more bearable.
And what about the registry? Shouldn't apps store their settings there, anyway? 5-10 years ago, registry was all the rage. These days, MS is advocating roaming profiles. Registry was never even integrated properly into Windows and now it seems to be on its way out.
Another thing on its way out: Start Menu. Let's not even get into that mess. The same story from
Documentsrepeat here, with everyone shoving everything where they want. No tags, no descriptions (or at least no one's using them). No rules for any kind of organization at all.And what about programs themselves? For legacy reasons, there are now two versions of "Program Files", and no easy way to tell where the thing you installed ended up (add to that the usual crap with
Company Name / App Name). Unless, of course, the thing is insideProgramData, which doesn't seem to fit with anything else.God forbid you have a portable app. There's no official place whatsoever where to place these. So people just create
C:\Games,D:\Toolsor whatever they want. Linux at least has/opt, so there's some sense of organization.Finally, what's with the mess that are environmental variables? Some apps insist on using them - probably because command line scripts can't easily access registry and system calls. But god forbid you try to edit these, as the GUI hasn't changed since Win 95 days. So is it OK to use env variables? Or should you use registry? Or app data? Who knows!?
Having a few consistent system calls hasn't helped keep any kind of organization, when every version of Windows came with its own idea on how to do things.
-
What's the intent of ProgramData?
My understanding of ProgramData is that it's for files that a program may change, but aren't user specific.
-
"Documents" was mentioned as the proper place. A terrible idea, but fine.
Compared to what?
Who the fuck thought that was a good idea?
Compared to what?
And what about the registry? Shouldn't apps store their settings there, anyway?
An app should store its settings there, yes.
5-10 years ago, registry was all the rage. These days, MS is advocating roaming profiles.
That is wrong.
Microsoft has spend the last 10 years or so downplaying roaming profiles. Roaming profiles is an ancient Windows NT4 concept.
Registry was never even integrated properly into Windows and now it seems to be on its way out.
There's two claims there, both of which could not be more wrong.
Another thing on its way out: Start Menu. Let's not even get into that mess. The same story from Documents repeat here, with everyone shoving everything where they want. No tags, no descriptions (or at least no one's using them). No rules for any kind of organization at all.
Compared to what?
And what about programs themselves? For legacy reasons, there are now two versions of "Program Files", and no easy way to tell where the thing you installed ended up (add to that the usual crap with Company Name / App Name). Unless, of course, the thing is inside ProgramData, which doesn't seem to fit with anything else.
I agree this situation sucks.
God forbid you have a portable app. There's no official place whatsoever where to place these.
Because Program Files suddenly and magically winks out of existence the instant an app claims to be "portable". Obviously.
So people just create C:\Games, D:\Tools or whatever they want.
People are allowed to do whatever the fuck they want with their own computer.
Finally, what's with the mess that are environmental variables? Some apps insist on using them
Wrong, stupid, buggy apps. Yes. Apps that don't need a console shouldn't be creating one solely for the purpose of asking for environment variables. That's stupid as shit.
probably because command line scripts can't easily access registry and system calls.
That is wrong.
But god forbid you try to edit these, as the GUI hasn't changed since Win 95 days.
Microsoft doesn't devote a lot of effort to things that were deprecated like 20 years ago. Why should they?
So is it OK to use env variables?
You can do whatever the fuck you want.
If you're shipping software, you probably shouldn't make it rely on environment variables unless you have absolutely no other way of accomplishing ... whatever it is you're doing.
Or should you use registry?
For what? It's impossible to answer these questions without knowing what it is you're trying to accomplish.
Having a few consistent system calls hasn't helped keep any kind of organization, when every version of Windows came with its own idea on how to do things.
Ok; you've now made this claim twice and have justified it zero times.
Either demonstrate it's true, or shut the hell up now.
-
"Documents" was mentioned as the proper place. A terrible idea, but fine.
Compared to what?
AppData is a better idea.
Linux also bollocks it up by saying apps should just save stuff wherever under
~and just add a dot in front of it, to make it better.OS X seems to be the best organized out of the bunch.
That is wrong.
Microsoft has spend the last 10 years or so downplaying roaming profiles. Roaming profiles is an ancient Windows NT4 concept.
Roaming profile = local profile, stuff under AppData, whatever you call it.
Where does Windows Store apps stores its local settings?
Hello fellow programmers, I am new to Windows 8. Where does Windows Store app's LocalSettings store its serialized file ? I am referring to this one: Windows.Storage.ApplicationData.Current.
Read The Registry Using Win 8 App?
I'm trying to see if it's possible to read the registry from a Windows 8 app. I can usually use Registry.GetValue() but I don't have that option when creating the Win 8 app. Doing some digging show...
Registry is on its way out, dude, at least as far as third party programs are concerned.
Because Program Files suddenly and magically winks out of existence the instant an app claims to be "portable". Obviously.
Oh, so should you use
Program Files? OrProgram Files (x86)? What if there are multiple binaries (both x64 and x86)? What if portable app wants to write data within its own directory, as it should?Get real dude. Windows needs an equivalent of
/opt, instead of each user inventing their own.probably because command line scripts can't easily access registry and system calls.
That is wrong.If it was easy, people'd use it, instead of using env.
Microsoft doesn't devote a lot of effort to things that were deprecated like 20 years ago. Why should they?
With their whole "Look at our cool new Console, let's write command line tools for ASP.NET, we love Linux, yay!" attitude as of late, it's getting de-deprecated pretty quickly.
Either demonstrate it's true, or shut the hell up now.
The mess inside my Start Menu and Documents is demonstration enough.
-
AppData is a better idea.
How is that:
- even a different idea, and
- a better idea?
OS X seems to be the best organized out of the bunch.
How?
Roaming profile = local profile, stuff under AppData, whatever you call it.
Those are three COMPLETELY different concepts. You have no fucking clue what you're talking about.
Oh, so should you use Program Files? Or Program Files (x86)?
I always put them in regular Program Files. I already said that I think having two different Program Files folders is a bad idea, what do you want from me?
What if there are multiple binaries (both x64 and x86)?
Then I guess you have to just scream and run out of the room, wetting yourself as you go.
You helpless infant, how about you just figure it the fuck out on your own?
What if portable app wants to write data within its own directory, as it should?
Why the fuck would it do that? It's always a bad idea to mix executable files with data files.
Get real dude. Windows needs an equivalent of /opt, instead of each user inventing their own.
Oh yeah
/opt. Obviously Windows needs something called/opt. And I know exactly what that is because the word "opt" is so self-explanatory. It's... uh... where to put your optometrist's files? I guess?If it was easy, people'd use it, instead of using env.
I move that they would not. I believe my position is backed by ample evidence.
With their whole "Look at our cool new Console, let's write command line tools for ASP.NET, we love Linux, yay!" attitude as of late, it's getting de-deprecated pretty quickly.
I think that's a shitty backwards move, also.
The mess inside my Start Menu and Documents is demonstration enough.
The bit that needs explanation is "every version of Windows came with its own idea on how to do things", which is so ludicrously false I can't even imagine how you'd come to think that.
-
Windows needs an equivalent of /opt
@blakeyrat said:Obviously Windows needs something called /opt.
Your literacy is slipping, @blakeyrat.
-
I always put them in regular Program Files. I already said that I think having two different Program Files folders is a bad idea, what do you want from me?
So you give your EVERY SINGLE portable program admin access so it can write stuff in its directory right? Because that's what portable apps do. That's what makes them portable. Like @cartman82 said.
-
So you give your every program admin access so it can write stuff there right?
No.
Because that's what portable apps do. That's what makes them portable. Like @cartman82 said.
Ok well whatever. I guess I don't use any "portable" apps by that definition.
-
I already said that I think having two different Program Files folders is a bad idea, what do you want from me?
Cut off your penis and mail it to him along with a signed letter of apology. Go on public television and admit your mistake to the world. Show them your dickless crotch and plead with God to send you to hell as it's the punishment you deserve. There, you put on a schoolgirl uniform and don a ballgag, and get sodomized by demons for a thousand years. Only then will your penance be complete.
Apparently.
-
How is that:
- even a different idea, and2) a better idea?
Roaming data is different than Documents, obviously.
Also, documents should be my place, for my shit. Not something every app uses as dumping ground for its own shit.How?
They have something like AppData that is wholly separate from user stuff. Also, stuff inside "Library" is well named and organized.
Those are three COMPLETELY different concepts. You have no fucking clue what you're talking about.
Yeah, whatever, I'm not into Windows Domains and shit like that. You know what I'm talking about: the directory
AppData\Roaming, where programs save data that should be moved between different machines.I always put them in regular Program Files. I already said that I think having two different Program Files folders is a bad idea, what do you want from me?
A name you can type as one word in a few letters would help.
Why the fuck would it do that? It's always a bad idea to mix executable files with data files.
Do you even know what "portable app" means?
Oh yeah /opt. Obviously Windows needs something called /opt. And I know exactly what that is because the word "opt" is so self-explanatory. It's... uh... where to put your optometrist's files? I guess?
Read what I said again.
I move that they would not. I believe my position is backed by ample evidence.
If you could do something like
%REG:LOCAL\My App\setting1%inside a shell script and get a value in a shell script, people would do it. Same with access to settings inside app data folder.The bit that needs explanation is "every version of Windows came with its own idea on how to do things", which is so ludicrously false I can't even imagine how you'd come to think that.
All the crap inside my
Documentsfolder that should be insideAppData\Roaming.
All the settings inside the registry that should be insideAppData\Roaming.
All the env variables that should be in the registry or wherever.
The mess inside my Start Menu, that can now only be useful through SearchThe proof is all around you. The Windows hasn't upgraded gracefully.
-
Cut off your penis and mail it to him along with a signed letter of apology. Go on public television and admit your mistake to the world. Show them your dickless crotch and plead with God to send you to hell as it's the punishment you deserve. There, you put on a schoolgirl uniform and don a ballgag, and get sodomized by demons for a thousand years. Only then will your penance be complete.
Apparently.
I'm not touching his tiny dick to get to the letter, no thanks.
-
Looking through my own Documents folder, it's a mess. Some apps create a proper subfolder with their full name. Others use strange abbreviations, or linux-like dot prefixes. Some create a company folder tree and organize their stuff there. I see a few that just dump whatever file they need directly inside "Documents". And then, there's stuff like My Games, which has the same sort of mess repeated inside it. And mixed with all this crap are my own documents and work items. Which are one name collision away from some installer deciding to "clean up" before proceeding. Who the fuck thought that was a good idea?
Just to be clear, it's fair to say that everyone that isn't creating a proper subfolder with company name is the problem here, not Windows.
Registry was never even integrated properly into Windows and now it seems to be on its way out.
Maybe for app settings, but it's not likely to ever go away, since COM more or less needs it, and .Net and whatever we're calling Metro apps (which are .Net) are built on that.
versions of "Program Files", and no easy way to tell where the thing you installed ended up
Well, except for the obvious "look in both folders". But MS' idea is that you shouldn't normally have to do that. The only good reason most of the time is to find your documents. If they're all in the Documents folder or that application's subfolder thereof, you mostly don't really need to go into Program Files.
God forbid you have a portable app. There's no official place whatsoever where to place these.
Well, no kidding. That's not really in Microsoft's vision, so they don't address it.My off the cuff thought is ProgramData, or maybe the Roaming Appdata directory. At least it would be consistent.
Finally, what's with the mess that are environmental variables?
Legacy reasons, mainly, I bet.
Some apps insist on using them - probably because command line scripts can't easily access registry and system calls.
Not really true--on modern systems (at least as far back as XP, IIRC), you could use reg.exe to query the registry. (I don't have as good an answer to "system calls"--but you could use PowerShell, probably, or something similar.)
Having a few consistent system calls hasn't helped keep any kind of organization, when every version of Windows came with its own idea on how to do things.
Well, most of that lack of organization is application programmers not following MS conventions. As has been mentioned, if they had used the API from day one, things would always wind up in "the right place" (at least as Microsoft defines it.)
-
More or less. From https://msdn.microsoft.com/en-us/library/windows/desktop/bb762494.aspx,
The file system directory that contains application data for all users. A typical path is C:\Documents and Settings\All Users\Application Data. This folder is used for application data that is not user specific. For example, an application can store a spell-check dictionary, a database of clip art, or a log file in the CSIDL_COMMON_APPDATA folder. This information will not roam and is available to anyone using the computer.
