LG webOS SDK
-
Well, the documentation states you have to install the Virtual Box, all around.
-
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.
Well, not really; .NET by default prefers to use App.config files, which, assuming you're using the System.Configuration API, will be put in the right place automatically.
-
I'm not touching his tiny dick to get to the letter, no thanks.
If you won't touch it, how are you going to mount it on your wall?
Do you mean you don't have a wall for this sort of thing?
Weird.
-
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.
Actually, under freedesktop specs they should be in
~/.config/org_name/app_name. Of course, same problem as always, people don't always do it...
-
Nope, not me, but I see the WTF extends platforms.
-
Also, documents should be my place, for my shit.
I agree.
Not something every app uses as dumping ground for its own shit.
There are a lot of buggy apps in the world.
They have something like AppData that is wholly separate from user stuff.
AppData is already wholly separate from user stuff. So...
You know what I'm talking about: the directory AppData\Roaming, where programs save data that should be moved between different machines.
Ok?
So now I know what you're talking about, what the fuck point are you trying to make about it?
A name you can type as one word in a few letters would help.
Why would you ever want to type it?
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.
You mean like:
Set path = CreateObject("Wscript.Shell").SpecialFolders("mydocuments")in VBScript?
All the crap inside my Documents folder that should be inside AppData\Roaming.
There are a lot of buggy programs.
All the settings inside the registry that should be inside AppData\Roaming.
I have no idea where this comes from.
All the env variables that should be in the registry or wherever.
THEY ARE! They exist in environment variables for backwards compatibility only.
The proof is all around you. The Windows hasn't upgraded gracefully.
None of those things have anything to do with changes in Windows at all.
-
Oh, so should you use Program Files? Or Program Files (x86)?
You should probably nearly always query for FOLDERID_ProgramFiles--you'll get the right directory based on whether your program is 32- or 64-bit (which means that a 32-bit installer for 64-bit program is probably a bad idea unless you know the workaround). You shouldn't use the X86 or X64 variants of that folderid unless you have a specific reason.
-
For legacy reasons, there are now two versions of "Program Files", and no easy way to tell where the thing you installed ended up
It just occurred to me that you might have both versions (32-bit and 64-bit) of a program installed and so need separate folders to house them as they would likely have the same name. Looks like it's this way with Java.
-
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.
The problem is MS didn't specify this properly, so everyone's doing whatever they want.
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.
Yeah, I expect it will gradually be relegated for Microsoft's internal use.
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.
Sure, I shouldn't have to do that. Except if I'm using it for portable apps, as blakeyrat suggests.
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.)
Is that supported everywhere? Will reg.exe be inside PATH? Will all the proper keys and subkeys be initialized? Will we have access rights? What's the syntax again?
Or we can just do the simple env variable.
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.)
Sure, there's the support in place to keep things consistent.
Microsoft has just been a terrible at influencing people to use it. Proven by the fact we couldn't find a simple offcial guideline like the one @blakeyrat wrote.
-
If you won't touch it, how are you going to mount it on your wall?
Do you mean you don't have a wall for this sort of thing?
Weird.
I have slaves for that, duh.
-
Actually, under freedesktop specs they should be in ~/.config/org_name/app_name. Of course, same problem as always, people don't always do it...
People are following these specs about as closely as Microsoft's nonexistent guidelines.
-
I already said that I think having two different Program Files folders is a bad idea, what do you want from me?
It certainly can lead to confusion.
How would you handle "I want to install both the 32-bit and 64-bit versions of an application" like Java, though? (I know how much you hate Java. Please don't let that derail any answer you may give.) The current system at least allows for a definitive way to do that, and it's one that you can fairly easily explain.
Why the fuck would it do that? It's always a bad idea to mix executable files with data files.
To keep all the files together in one place. The idea of a portable app here is "something I don't have to use an installer for, but can keep (for example) on a USB drive and move from system to system on demand."
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?
What does "opt" mean (as in the "opt" directory)? Is it an abbreviation?
What does "opt" mean (as in the "opt" directory)? I commonly see this directory in Unix systems with development tools inside. Is it an abbreviation?
-
It just occurred to me that you might have both versions (32-bit and 64-bit) of a program installed and so need separate folders to house them as they would likely have the same name.
That was Microsoft's original rationale, and I think the application that prompted it was Internet Explorer. (With the whole add-ins thang.)
A better solution IMO would have been to put the 64-bit one in
Program Files/Internet Explorer x64or something similar.
-
Your literacy is slipping, @blakeyrat.
I have long suspected, but realized for sure, the other day, when he mentioned deliberately missing things you are supposed to notice in his Let's Plays, that he deliberately misunderstands on purpose.
Now you know, too.
-
t just occurred to me that you might have both versions (32-bit and 64-bit) of a program installed and so need separate folders to house them as they would likely have the same name. Looks like it's this way with Java.
Yeah I believe something like that was the reason.
-
It certainly can lead to confusion.
I think having different Program Files directories is perfectly reasonable. The way they ended up trolling us with WoW64 and
System32is, however, diabolical.
-
Ok well whatever. I guess I don't use any "portable" apps by that definition.
If you have any interest in what they're talking about--and I assume you don't--look at portableapps.com. As I said in a previous post, it's basically a way of having, I guess, a minimal administrative footprint, and the ability to move an app easily from one system to another. Just unzip a package, generally, onto a USB drive, and carry it from machine to machine. If you want it to run a bit faster, you can just copy it to its own directory on the hard drive of a given machine.
-
People are following these specs about as closely as Microsoft's nonexistent guidelines.
Well, I'm using a rather sane API for my measly desktop programming needs so I don't even have to make a concious effort at doing it right.
Settings-wise, that is. Install dirs... yeah, I'm on my own there.
-
A name you can type as one word in a few letters would help.
That's another thing that was done deliberately: MS used "Program Files" instead of "Programs" to force developers to get used to names with embedded spaces and long file names.
Clearly many developers weren't up to the task.
-
that he deliberately misunderstands on purpose.
All the time.
But only when I'm making a point. If I say I'm genuinely confused about something, I usually am.
-
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.
-
(You shouldn't be grabbing the known folder paths from the registry, either. That's implementation detail.
Use the API built for the purpose and ONLY the API built for the purpose.)
-
Well, not really; .NET by default prefers to use App.config files, which, assuming you're using the System.Configuration API, will be put in the right place automatically.
That's not what I meant. COM is used internally even by universal apps or whatever they're called this year. (Not to mention if you're doing Interop with non-COM stuff, although that wasn't what I was thinking of.).
That shit will probably never go away as long as Windows exists in a form that's recognizably compatible with what we have today.
-
THEY ARE! They exist in environment variables for backwards compatibility only.
Not only that, but sometimes individual registry keys also only exist for backcompat, and you're supposed to use an API call to get the information.
-
It just occurred to me that you might have both versions (32-bit and 64-bit) of a program installed and so need separate folders to house them as they would likely have the same name. Looks like it's this way with Java.
This is exactly why they did it.
-
Also, documents should be my place, for my shit.
I agree.
Not something every app uses as dumping ground for its own shit.
There are a lot of buggy apps in the world.
Wasn't your original claim Documents is the proper place for app data?
So now I know what you're talking about, what the fuck point are you trying to make about it?
That something like that should have been strongly pushed by MS from the get go, instead of apps dumping their shit in
%User%\Documents,%User%\Documents\My Games\Mycrappygamealllowercase,%User%\Documents\Company\Section\Product\Version\Blah,%User%\abcdand wherever else they decide.You mean like:
Set path = CreateObject("Wscript.Shell").SpecialFolders("mydocuments")
in VBScript?
That's just slightly crappy. Now use registry instead of environmental variables.
None of those things have anything to do with changes in Windows at all.
Switching to and from the registry, Documents vs AppData, moving away from free folder structure and not giving anything to replace it (the "
/opt" equivalent), deprecating env but not really... MS changed their mind A LOT, and didn't properly communicate their new best practices. Thus the current mess.
-
COM is used internally even by universal apps or whatever they're called this year.
Unless MS has radically redesigned the .NET runtime, that's not true; the COM Interop exists to allow assemblies to call COM components and vice versa, but .NET itself is not built on COM.Remember: the .NET runtime is like the Java runtime; they're both VMs on top of, in this case, Win32.
-
That's another thing that was done deliberately: MS used "Program Files" instead of "Programs" to force developers to get used to names with embedded spaces and long file names.
Clearly many developers weren't up to the task.
Basically, they've proven that the gun works by shooting themselves in the foot.
Idiots.
-
The problem is MS didn't specify this properly, so everyone's doing whatever they want.
Well, I think we fall into semantics at this point. I recall reading this shit on MSDN before XP came out. Lots of people don't look there except for specific things.
I think a fairer claim is they didn't push the information sufficiently.
Yeah, I expect it will gradually be relegated for Microsoft's internal use.
I am not going to go looking for it, but a few months ago I was looking at modern-style apps from a development perspective and I ran into something that fairly prominently featured registry-related stuff. I can't remember the context, which is a bit annoying since I can't explain it well, but it sure looked to me like "this stuff would be pretty low-level hard-to-rip-out" stuff that suggested that some usages of COM are going to be around for a long time.
And of course, as I said in another post, which you wouldn't have gotten to when you wrote the one I'm replying to, if you want to interop with non-.Net stuff, you're going to need to use COM.
-
Wasn't your original claim Documents is the proper place for app data?
Quote me.
I fucking dare you.
I double-dog dare you.
That's just slightly crappy.
Crappy or not, it's one line of code, it works, and it's the correct way of doing it.
Now use registry instead of environmental variables.
Huh?
That code doesn't use the registry or environment variables.
Switching to and from the registry,
The "switch" to the registry happened when the OS was brand new, any Win32 app should have been using it from day one.
The "switch" away from the registry is some fictional thing you keep claiming exists, but I see no evidence for at all.
Documents vs AppData,
Huh? Those are completely different concepts.
moving away from free folder structure and not giving anything to replace it
What is "the free folder structure"? You're introducing new concepts here we've never discussed before and acting as if I should know what the hell you're talking about.
deprecating env but not really...
Huh? It's been deprecated for ages.
MS changed their mind A LOT,
Not one of those examples demonstrates this point.
-
Is that supported everywhere? Will reg.exe be inside PATH? Will all the proper keys and subkeys be initialized? Will we have access rights? What's the syntax again?
Define "everywhere", but I'd be tempted to say "yes". Of course it's in path: it's in system32! Your next question is gibberish--reg can be used to query the registry, create/modify/delete keys and data values, and several other things. If "the proper keys and subkeys" aren't initialized, whatever that means, then no method of registry access will find them. Your access rights are going to be whatever they already are--reg.exe is basically just a thinnish wrapper around ADVAPI32. The syntax can be found by using "reg /?".
Or we can just do the simple env variable.
Sure, if you want to fuck around with something that may not be correct. Not all environment variables are tracked realtime. IIRC if you open one command prompt, and then, in another application, change a variable, that change doesn't get migrated back to the prompt, because each process initially gets a static copy of the environment as it existed when the process was initiated.
-
Microsoft has just been a terrible at influencing people to use it.
No argument there.
-
A better solution IMO would have been to put the 64-bit one in Program Files/Internet Explorer x64 or something similar.
I actually do something like that on my home machine, where I have a small SSD and a big HDD: Most of my programs are on d:\apps. I put Java in Java32 and Java64 under there.
Having two separate top-level directories and segregating applications by bitness probably was the brainchild of some kind of purist.
-
Quote me.
I fucking dare you.
I double-dog dare you.
Hmm, I guess my bad.
You did claim DropBox should go there, which is wrong. It should either remain where it is, or go to appdata. Must have picked up that and mixed it up.
Huh?
That code doesn't use the registry or environment variables.
I mean, write code that uses value from registry and compare it with code that uses env.
The "switch" away from the registry is some fictional thing you keep claiming exists, but I see no evidence for at all.
Modern and universal apps don't count?
Huh? Those are completely different concepts.
They should be. But they are treated as same by a bunch of apps. Some of them developed my Microsoft.
Huh? It's been deprecated for ages.
And it's coming back with Win 10 and new .NET stuff.
-
The way they ended up trolling us with WoW64 and System32 is, however, diabolical.
Yes, but you understand why they did it, right? You can certainly argue about it, but you have to filter everything MS does through the lens of backcompat.
-
Settings-wise, that is. Install dirs... yeah, I'm on my own there.
Unless you have a good reason not to follow the MS guidelines, you should do it in the future, though.
-
Yes, but you understand why they did it, right?
That's boring. It's still a retarded end result. Let's be honest and state that they at least could have given WoW64 a less misleading name.
-
But only when I'm making a point. If I say I'm genuinely confused about something, I usually am.
If you follow the link I posted about /opt, it means "option" as in "optional software packages". Generally speaking, you should put third-party software in /opt in Linux.
-
(You shouldn't be grabbing the known folder paths from the registry, either. That's implementation detail.
Use the API built for the purpose and ONLY the API built for the purpose.)
Oh, absolutely. That's why I chose the key I did: you generally wouldn't want to look at that particular key for anything.
-
You did claim DropBox should go there, which is wrong.
In Documents?
No, that is not wrong.
I mean, write code that uses value from registry and compare it with code that uses env.
You lost me. Why would you do that?
Both the registry and environment variables are the wrong way to get these paths. Use the API call provided by the OS, that is the only correct way.
Modern and universal apps don't count?
AFAIK they don't replace traditional Windows apps which are expected to use the registry.
They should be. But they are treated as same by a bunch of apps. Some of them developed my Microsoft.
Microsoft writes bugs too.
And it's coming back with Win 10 and new .NET stuff.
That all uses PowerShell, which can use the .NET functions to call the Windows API properly. AFAIK, environment variables are still deprecated.
-
Did you upgrade from XP? Is that why you've still got a c:\documents and settings?
Windows 7 has "Documents and Settings". True, it's a junction to \users...
-
That's just slightly crappy. Now use registry instead of environmental variables.
set shell = CreateObject("Wscript.Shell")
msgbox shell.RegRead("HKCR\Forms.CommandButton.1\CLSID")
-
You lost me. Why would you do that?
Both the registry and environment variables are the wrong way to get these paths. Use the API call provided by the OS, that is the only correct way.
Yeah, at some point we switched from "get system paths" to "store configuration in general".
Whatever. The point is, people are lazy. MS should have made the right things easier than the wrong things. They didn't, thus the people keep using the wrong things.
You blame the people. I blame MS.
AFAIK they don't replace traditional Windows apps which are expected to use the registry.
Universal apps will.
I can't find anything whether registry will be available, but since I'm pretty sure it's not on WP and it definitely isn't on other platforms MS wants to cover, my take is registry will quietly fade into background.
That all uses PowerShell, which can use the .NET functions to call the Windows API properly. AFAIK, environment variables are still deprecated.
Are you saying when you type a program name into powershell, it will use something other than PATH variable to look it up? Because that's what it'd take.
-
Whatever. The point is, people are lazy. MS should have made the right things easier than the wrong things. They didn't, thus the people keep using the wrong things.
Seriously?
And you write software? For a living?
-
Seriously?
And you write software? For a living?
Trust in systems, not people, blakey. That way you won't be disappointed.
-
That's boring. It's still a retarded end result. Let's be honest and state that they at least could have given WoW64 a less misleading name.
Stipulated. What's your suggestion?
-
Windows 7 has "Documents and Settings". True, it's a junction to \users...
It's also deliberately busted and using it is Doing It Wrongâ„¢
-
Trust in systems, not people, blakey. That way you won't be disappointed.
You just said, "I'm so lazy I don't give a crap about writing bug-free software, and not only that, but I think everybody should be like me."
What reaction did you expect? You're despicable.
-
buggy
You know what? You've proven your inability to use that word. I'm going to make a script that changes any time you say "buggy" into... Anything else.
THOSE ARE NOT BUGS. THEY ARE POOR DESIGN. THEY ARE NOT THE SAME THING.
-
Unless you have a good reason not to follow the MS guidelines, you should do it in the future, though.
I'm actually not deploying to Windows, but I agree.
For reference, without changing a thing in my settings handling code it will all go to registry on Windows. At least that's what the docs claim. Whether it's a good or a bad thing... dunno. But I'm convinced it will work at the very least.
