LG webOS SDK
-
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.
You got me. That's exactly what I said, word for word.
My life moto in one pithy saying.
-
Oh, I found out what I was thinking of!
WinRT is based on COM, universal apps--which aren't necessarily the same as modern apps, I think--run on WinRT. So it wasn't quite what I was thinking of.
Universal Windows Apps with XAML and C# Unleashed
Full Color: Figures and code appear as they do in Visual Studio. Universal Windows apps are a total game-changer. You can now write once and deploy your app to any modern PC, tablet, phone, or other Windows device. Suddenly, it's quick and easy to serve new devices and form factors, sharing...
-
Did you mean to link to a page in that book? It's not one I can access.
Edit: Never mind, found the page. Not sure it confirms, but fuck it, close enough for me
-
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.
AHAHHAHAHHAHA
No.
Even if you use a centennial bridge to convert an application, it gets a sandboxed version of the registry, not no registry.
It actually sandboxes all this broken stuff that people mess up.
-
@blakeyrat said:
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.
Yeah, the biggest advantage is for people like myself who regularly have to use computers that we don't have admin rights on but can run arbitrary programs on. I can run my portable stuff from a flash drive and not have to worry about leaving cruft behind and re-configuring on each machine
-
Will reg.exe be inside PATH?
Since reg exists in system32, it better be.
@cartman82 said:
Will all the proper keys and subkeys be initialized?
Huh?
@cartman82 said:
Will we have access rights?
It's the registry. Access rights don't change because you're accessing it via reg.exe.
@cartman82 said:
What's the syntax again?
reg /?
(no, I'm not going to paste that output here)
Well, that was easy...[edit]:
'd
-
'Modern apps' is a good description of the UI style Microsoft has been pushing for since 8. But it only means the UI style, and not anything else. WinRT apps are now generally called Universal apps, because they're supposed to run on all versions of Windows, but also theoretically include centennial apps, which are simply sandboxed Win32 apps with store deployment and the ability to add on WinRT features, and aren't really crossplatform like the rest. Photoshop will be one of these SoonTM.
-
Not only that, if he loves unix, he can use powershell and type
man regmost likely!EDIT: Apparently that doesn't know what reg is, so it just turns up a search. Oh well.
-
-
I did say I found it
-
centennial bridge
I am curious what you were going for here, because I'm sure "centennial" isn't the right word.
ETA: Never mind.
-
centennial apps
Oh--now I think I see. You must be talking about the lower-left section on this page ("Classic Windows apps").
-
I did say I found it
Yes, but now we know you found the page I was thinking of, and not some other random page that independently confirmed said page.
-
I'm talking about Project Centennial, which, yes, is the classic Win32 part of that. That's what the people responsible for it called it during //build.
-
I'm talking about Project Centennial, which, yes, is the classic Win32 part of that. That's what the people responsible for it called it during //build.
Yeah, that's why I edited my first post. This was the first time I'd heard the term, although I'd heard about the idea of putting desktop apps in the store.
-
Why would anything be under C:\programdata? Where did that come from?
CSIDL_COMMONAPPDATA. Used for program-specific data that isn't tied to any specific user. Usually used for things like data patch files or system-related configuration (tools paths, hardware, etc)@aliceif said:How does My.Settings tie into the whole Windows special folders paradigm?
For application settings, they're saved in the App.config file (programname.exe.config) next to your app's EXE (usually in Program Files, can only be changed by an administrator). For user settings, they're saved in an XML file in the same format, in[CSIDL_LOCALAPPDATA]\Company Name\Product Name.@cartman82 said:Looking through my own Documents folder, it's a mess.
That's the fault of your terrible applications.@cartman82 said:Some create a company folder tree and organize their stuff there.
For applications that are not games, this is correct.@cartman82 said:And then, there's stuff like My Games, which has the same sort of mess repeated inside it.
For applications that are games, this is correct.@cartman82 said: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.
23 years ago, Microsoft created the Registry as a centralized "settings store", both for its own use and for applications. It worked correctly with multiple user profiles and uninstall/reinstall, which per-program INI files (the guidance for DOS and Windows 3.1) did not. It also worked properly when roaming user profiles were introduced -- which INI files probably wouldn't unless care was taken. It was integrated properly then, and is integrated properly now. However, the Registry has become quite large, and is now getting too slow to roam as a unit across a dial-up VPN connection -- or too big and unwieldy to roam via SkyDrive. For that reason, Microsoft is starting to advocate using the Settings section of Windows Storage, which keeps things modular and granular so things can roam more "nicely".@cartman82 said:Another thing on its way out: Start Menu. [...] No rules for any kind of organization at all.
It's supposed to use the same rules as Program Files, Documents, and App Data:[CSIDL_Whatever]\Company Name\Product Name. Microsoft opted not to actively enforce those rules, to give the user choice, which resulted in applications making terrible choices on behalf of the user. @cartman82 said:Unless, of course, the thing is inside
The only things that should be insideProgramData, which doesn't seem to fit with anything else.ProgramDataare program data, not programs. SQL databases, or the Guild Wars data package, or the latest regulations file for EVE. Not Chrome.@cartman82 said:God forbid you have a portable app. There's no official place whatsoever where to place these. So people just create C:\Games, D:\Tools or whatever they want. Linux at least has /opt, so there's some sense of organization.
Well yeah, they're portable: the whole goal is to have no official place.@cartman82 said: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!?
You should use the Registry or Windows Settings Storage for settings, AppData for data files, and Documents for "things the user considers theirs." The environment is there as a convenience; it is not guaranteed to be correct or even consistent, so you should use the actual system calls instead.@blakeyrat said:And I know exactly what that is because the word "opt" is so self-explanatory.
Options, as in "optional software I just want to throw on here, but that AT&T will know toignorebreak and charge me an arm and a leg for "unauthorized motifications". Oh hey, there's that 1970's timepod!@cartman82 said:They have something like AppData that is wholly separate from user stuff.
Like, you know, ProgramData?@cartman82 said:Also, stuff inside "Library" is well named and organized.
Yeah, by using the company domain name and app name. OH MY GOD THAT'S COMPLETELY DIFFERENT!@cartman82 said:A name you can type as one word in a few letters would help.
\Pro↹.@cartman82 said:All the crap inside my
Microsoft's been giving the same guidance on that since 1996. Not their fault idiot devs don't listen.@cartman82 said:Documentsfolder that should be insideAppData\Roaming.All the settings inside the registry that should be inside
Settings go in the registry; it roams too. Things that are files and not settings go inAppData\Roaming.AppData\Roaming. This isn't new.@cartman82 said:All the env variables that should be in the registry or wherever.
They are. That's where the environment gets them from. Programs should too, but POSIX compatibility...@cartman82 said:The mess inside my Start Menu, that can now only be useful through Search
Blame the moronic companies that are responsible for that, not MS.@FrostCat said: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.)
The output fromreg.exeisn't amenable as input to theSETbuiltin, so it can't be used in later batch file flow control. Unfortunately. This is why PowerShell is better.@FrostCat said:(which means that a 32-bit installer for 64-bit program is probably a bad idea unless you know the workaround).
Just use MSI!@cartman82 said: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?
Yes, yes, yes aside from the ones you shouldn't be using anyway, probably, I don't know but/?does.@RaceProUK said: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.
But the entire GUI system is. Including pre-2.0 WinForms and all of WPF.@cartman82 said:You did claim DropBox should go there, which is wrong.
No, this is correct. DropBox should put its settings in the Registry, any have-to-be-files configuration in roaming app data, its sync cache in local app data, and all of your stuff in Documents -- the place for your stuff.
-
-
W32oW64?
-
Sys32Compat or similar?
-
Anything with 32 in the name would be an improvement.
W32oW? Yeah, that's obviously much better!
-
W32oW? Yeah, that's obviously much better!
At least we agree on something.
W32oW64?
W32
W32E
W32MSys32Compat or similar?
It's almost like...you could figure out what it does just from the name!
-
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW?<descriptive
-
-
Tough question for you: how do you obtain the path corresponding to CSIDL_LOCALAPPDATA in an app that's written to use a different subsystem than Win32?
-
Tough question for you: how do you obtain the path corresponding to CSIDL_LOCALAPPDATA in an app that's written to use a different subsystem than Win32?
Not even sure what you mean. What "different subsystem"? (What even is a "subsystem"?)
EDIT: ok the Wiki pages for Windows NT mentioning the word "subsystem" about 47 times before bothering to define it in any way. Basically you're asking how you get those paths if you're running in OS/2 or POSIX mode? I have no idea. It's also not something likely to ever come up, since both of those subsystems are as near dead as is possible without actually being dead.
If you're talking about how to get it from an environment like Ruby or Python or what-not, it's the responsibility of whoever wrote the Ruby or Python or what-not runtime to provide that capability for you. Same way .NET and VB or WSH are responsible for providing access to it.
-
since both of those subsystems are as near dead as is possible without actually being dead.
I think they finally ripped out the POSIX one in 8, partly because it was slower than running something like cygwin.
-
Right; but it was "basically dead" long before then. I remember it being a novelty even when XP was current.
The OS/2 one, I didn't even know existed (although it makes sense, since IBM/Microsoft had that weird cross-compatibility deal way back when NT3 was competing with OS/2.) I bet it's been defunct for decades now.
-
I didn't know about that one either. I only found out about the POSIX one a year or two ago, and almost immediately learned that if you want to use it, you should probably be using something that works better. And then it was gone. I like that they bothered in the first place, and that Windows was more POSIX-compliant than Linux.
-
And then it was gone. I like that they bothered in the first place, and that Windows was more POSIX-compliant than Linux.
Microsoft also produced a JVM significantly better than Sun's for many, many years.
One of the reasons Sun got all pissy is that Java developers in Windows could actually make Java apps look and act somewhat reasonably native, when the Sun JVM couldn't get anywhere close. This wasn't because of some evil scheme by Microsoft hiding APIs from the competition, it was just because Microsoft actually gave a shit in a way Sun never did.
-
Well, at the same time, they extended Java in ways that only worked on Windows, which I can understand them getting mad about. It reeks of the 'only on ie6' features that Microsoft is so infamous for, and which Google is emulating for all they're worth.
-
Well, at the same time, they extended Java in ways that only worked on Windows,
Right; SO JAVA APPS COULD WORK CORRECTLY WITH THE OS.
Sun should have been thanking them, integrating the changes into their own JVM, then started programs to do the same sort of work on Macs and Linux machines.
It reeks of the 'only on ie6' features that Microsoft is so infamous for,
I've never heard of that before, so they can't be that infamous for them.
-
I've never heard of that before, so they can't be that infamous for them.
Sorry, but I only have experiences with reality on the planet generally referred to as Earth, so I can only talk about the sort of general knowledge that comes from there. If you come from somewhere else, your experiences may vary.
-
You seem to be the only one on the Internets who has ever used that phrase before.
-
It's cool that you searched a specific thing I said, rather than thinking about it, but I guess you're treating everyone the way you've asked to be treated. It's too bad that that's completely separate from the way the rest of society works.
-
-
I've never heard of that before, so they can't be that infamous for them.
See Also: ActiveX controls
-
-
-
-
This wasn't because of some evil scheme by Microsoft hiding APIs from the competition, it was just because Microsoft actually gave a shit in a way Sun never did.
Yeah--the MSJVM of the time was far, far, faster than the Sun one.
Sun's actual claimed beef that ultimately led to the retiring of the MSJVM was that MS added a couple of functions to a couple of classes that--if developers used--would create class files that weren't cross-JVM-compatible. I remember looking into the actual functions at the time and thought Sun was being overwrought about it.
-
Well, at the same time, they extended Java in ways that only worked on Windows, which I can understand them getting mad about.
It literally was a small handful of functions in about 3 classes, btw.
-
The extent to which they did it isn't the problem. It's the false idea that they were 'taking ownership of java' by doing so. Even though it was untrue, they wont allow anyone else to give the appearance of taking control from them, which isn't unreasonable.
-
If they wanted to maintain control, why did they let Microsoft build a JVM in the first place?
I don't think that was the true reason behind it. I think the fact that Microsoft was badly embarrassing their incompetent developers was at least part of the problem.
Developers weren't flocking to the Microsoft JVM because they hated Sun or hated cross-compatibility. They were doing it because Microsoft's JVM was so much better that it was worth making cross-compatibility a tiny bit more difficult. (Assuming it even was. Which I doubt.)
-
Definitely. My point is that it's all looks.
-
The extent to which they did it isn't the problem. It's the false idea that they were 'taking ownership of java' by doing so. Even though it was untrue, they wont allow anyone else to give the appearance of taking control from them, which isn't unreasonable.
Sun could have simply told devs "don't use [list of functions] and you can avoid compatibility problems". Forcing MS to pull the MSJVM (after, of course, years of legal maneuvers and millions of wasted dollars) probably helped set Java back years, because the MSJVM was just so much faster it isn't even funny. It probably took about 2 generations of hardware for Sun's JVM to catch up.
-
Well I've got a good deal of stuff there, some of which is Microsoft stuff. What's the intent of ProgramData?
IIRC, it's the original location that
CSIDL_COMMON_APPDATAtargeted; it got changed to be something under the All Users profile at some point. Everybody seems to ignore that, though.
-
Forcing MS to pull the MSJVM (after, of course, years of legal maneuvers and millions of wasted dollars) probably helped set Java back years, because the MSJVM was just so much faster it isn't even funny.
It killed Java on desktop PCs almost-entirely. If not for the fact people use desktops to develop Java server software, and the pacemaker that is Minecraft, Java'd be utterly dead on desktops.
Sun was damned lucky that at the same time they were committing suicide on PCs, some enterprising mobile phones like my old RAZR were adopting Java-on-a-chip.
-
If not for the fact people use desktops to develop Java server software
Which is like saying “apart from the elephant in the refrigerator”.
-
@Magus said:
Well, at the same time, they extended Java in ways that only worked on Windows,
Right; SO JAVA APPS COULD WORK CORRECTLY WITH THE OS.
Sun should have been thanking them, integrating the changes into their own JVM, then started programs to do the same sort of work on Macs and Linux machines.
It reeks of the 'only on ie6' features that Microsoft is so infamous for,
I've never heard of that before, so they can't be that infamous for them.
Are you kidding that's the most infamous thing Microsoft ever did!?
-
Are you kidding that's the most infamous thing Microsoft ever did!?
Have you even heard of "only on IE6" features before? Am I crazy here, or is Magus?
Embrace, extend, and extinguish - Wikipedia