Re: OT: Win 7 comments

Daniel Johnson stated in post 4dydnXaEU9FHN2XXnZ2dnUVZ_sadnZ2d@xxxxxxxxxxxxx
on 11/9/09 4:50 PM:


It's putting compatibility above consistency, certainly, but it seems like
an obvious call in this case.

Don't programs just call a "standard" dialog? If so, the dialog can be
changed (though assumptions about how it communicates with programs must be
respected).

Yes, they do, and in some cases the old API can summon the new dialog. But
this is the exception, not the rule. If you do anything interesting at all,
you get the old dialog. It's safer so.

The dialogs are pretty much the same other than the look... just change the
look of the old one and keep the same functionality... do not even modify
the code for the "hooks".

[snip]
So it seems. Did they ever fix the way Safari's size grip would disappear?
That always annoyed me.

I have not seen that... other than when the "grip" is off the screen. That
happens when I move a large window to a smaller monitor. :)

No, I mean when you resize Safari, and the grip doesn't get redrawn.

Just tried to replicate... could not. Does not mean it never happens, of
course. Can you show an example?

[snip]
I used to run into a setting error with Paint all the time. I do not remember
the steps, but it was something my K and 1st grade students would accidently
do which would make some aspect of the program go away. I know the color
selector and tools can be turned on and off by menus... maybe it was the
window would be off the screen and I could not move it with the move
command... I do not recall. Anyway, I was able to find a fix online, but it
involved altering registry entries. I set up a .reg file to make this
easier, but on OS X I would be able to just replace or lock the .plist file.
I have run into a number of other similar situations... though none so easily
repeated. I know I wrote about it at the time... darn, wish I could remember
the details better.

If you knew what your students had done, you could no doubt undo it via the
same UI they had used to do it.

I know I tried at the time. Though looking at old posts all I find is this:

I have seen this just as often on XP as on OS X. Used to have a
class where I did a lot with Paint (to teach how to use a mouse,
etc.). It would often get hosed. I had to edit the Registry. Yuck.

and:

* Fixed settings in Paint that could not be corrected with the GUI

I fear neither is very specific. Drat.

Where OS X is weak here is that I cannot lock parts of a plist - it is all or
none. I wish I could do so in a more granular way.

You can delete parts of plists, can you not?

Yes... but not lock some parts and leave others open for modification. Not
that I know of anyway.

[snip]
I've done it. Deleting preferences from the registry works just fine. It's
not something you are likely to need to do, any more than on a Mac.

Finding items in and working with the registry is a lot more hazardous than
is tossing plist files.

Not really. There are some parts of the registry that are dangerous to change,
but there are plists like that, too, if I recall.

You might be able to hose things by writing things to a plist, but there is
not a single plist I know of you cannot just remove.

And you cannot just edit a part of the registry without opening regedit or
the like... or using a .reg file I guess. With OS X, just toss the file...
if you edit it and goof you can always do that. Also easy to back up...
just make a copy with the OS... or use Time Machine to get back that *one*
file.

You can use old versions of the registry to export keys and then import
them... but that is far more work.

And on Windows, deleting preferences is not a time-hallowed ritual for
exorcising demons from the computer. We use reinstallation for that! :D

Yes... because systems get fried. OS X is, from what I have seen,
re-installed far less often.

People don't reinstall because "systems get fried"; they do it because it's
what they've learned to do in lieu of real troubleshooting.

Well, it is a brute force method.

OS X is reinstalled less often because you have different rituals to follow.

Seriously; this stuff is like my declaring that Macs are junk because you
have to repair permissions all the time. But it's just not true: it's a
ritual Mac users do, but it isn't OS X's fault that this happens.

There are times it helps... again, read the ScreenFlow forums for people who
have done it and had it work. Quite a few examples.

[snip]
Well, hopefully the 'problem reports' thingy figures out what's gone wrong
for you, and then you realize it's not the registry, and perhaps you can
then fix it.

Preferences in the registry do get "fried". It happens... just as plist
files can go bad. When a program crashes or the like they do not always
leave things as they should.

Well, the registry is unfazed by that sort of thing, of course. It's very
robust that way; even the blue screen of death will not corrupt the registry.

But even plist-files surely take precautions against app crashes. It's not
particularly hard to do so.

Yet both can get fried. I have seen it many times.

On OS X you just toss the plist file... most cases you are done.

This is right up there with repairing permissions, in my view.

Often works. Then again, so does repairing permissions. Read the
ScreenFlow forums for many examples of it solving things for people. With
OS X, I know a common permission problem can make menus go wonky... not
switching to the right one when the program is switched to. Fixing
permissions corrects that.

There's no technical mechanism for permissions to interfere with menus, of
all things. I do not find this credible.

I do not know what permission caused the problem, but that is Apple's
suggested fix. And it has worked on at least two machines I know of.

Real troubleshooting involves figuring out what has gone wrong.

I cannot tell you what file is messed up to do what I described, but I have
seen it resolve the issue.

You have seen it, perhaps, change the symptoms. But if you can't say what went
wrong, you can't credibly claim to have fixed it.

I know there was a repeatable problem that ceases happening after the
procedure. I could have tried to track it down more than that, but frankly
it does not matter that much to me. If I see it a lot, though, I might get
more curious and try to find what is getting messed up.

Out of curiosity: what troubleshooting steps would you have suggested?

If not, run YASU or Onyx or a similar utility which runs the "standard"
troubleshooting stuff of OS X (toss caches, check drive, check permissions,
etc.).

This rather sounds like snake oil. And yes, there's vast amounts of similar
snake oil being sold for Windows. But none of these things even look at the
problem you are having.

It is a cure-all without finding the cause. No doubt. But often works.

At best, these jiggle enough things so that the symptoms change. But the
underlying problem, whatever it is, remains.

Sure: their still may be an installer that causes problems or some bug in
some program or whatever... but if the problem is gone and does not come
back, I am not sure it matters. If it becomes recurring, of course, more
should be done.

For instance, suppose you do have corrupted caches. You toss them, and is
your problem solved? No. something corrupted them, and will do so again.

Yes... as I said, it does not find the cause. I had some bad fonts... once
those were removed I still had problems until I cleared the font caches.
Makes sense.

Exactly. If you know "Oh, my Garbana Extra Ugly Bold Italic Underlined font
file is corrupted!", then tossing caches can make sense as part of the
solution. But you can't just do that, you have to remove or replace that font
file too.

Right... and I did. :) I am not sure, though, what process works with the
font caches. Maybe something can corrupt them (or other caches). If it is
a rare thing that does not reoccur, not really a big deal. For me. For
Apple, of course, they would want to know because even a rare thing will hit
a number of users!

But, really, without taking lots of time, if you run into a problem and do
the catch-all to resolve it, and then it does not come back... what else do
you suggest one do?

With these programs you do not discover the underlying cause of the problem,
and therefore do not correct it.

True enough... but often the problem never comes back.

It comes back. Maybe the symptoms are different the next time, and you think
it's a new problem.

The funny thing is, I know Mac users "troubleshoot" just as you have
described. Yet they do not conclude that plists are crap because of it.

That's odd, consider how some of you guys bring the same habits to Windows,
and then decide the registry is crap because of it. :/

Are you just denying that the registry gets corrupted?

The disc check one is particularly dangerous: if that's helping at all,
you've got a very serious problem with the computer- like a bad hard
drive.

It checks the drive not just for drive errors but file errors... btree
problems and the like.

HFS+ is journaled. That kind of thing should simply not happen. If it has
happened, something is badly wrong somewhere. Frankly, a dying hard disk is
the most likely culprit.

I have seen btree problems. It happens. And without the drive dying any
time soon.

(Speaking of that, did you know that since Vista Windows has monitored hard
disk SMART status? Lets you know if a disk is about to go. Maybe.
Sometimes.)

I think OS X checks START on boot. Maybe. Would have to check. Does not
do continual checking though.

If the user thinks the disk check has fixed it, he's in for a nasty shock
when the drive fails completely.

If there is a hardware problem. I know at least Onyx at least does a SMART
check.

That's useful. That can diagnose one genuine underlying problem: worn out
hardware. Darn those moving parts!

Well, the problem is if they stop moving. :)

[snip]
This was not a driver: it crashed before it ever installed the new driver I
wanted. It wasn't even the installer, but a runtime library.

Ah, I see. Yes. With any installer that is crashing, though, looking for a
newer version is a standard step. Did you need Windows to tell you that?

I thought so too. This was the newest version of the installer, but I tried
reinstalling older ones, since I at first thought the latest was busted. But
no joy.

Wait: so what was the fix?

[snip]
Indeed, but the thing works on pretty much application crash, at least.

I will wait for some apps to crash. I did have one which froze and could
not be force quit, but it has not happened since.

Yeah. Windows tries to be smart and detect non-responsive apps, but you can
get one into a state where it's just responsive enough to not trigger the
"ya want me to off this one, boss" dialog. Then you have to use task
manager, which can be a bit confusing.

Even with the task manager it would not quit. Never saw that with XP...
that I recall.

At least they finally fixed the tab background color in task manager,
though.

[snip]
Maybe so; but if you're going to OS X to obtain security by obscurity, you
should be aware that it's far from the best choice for that.

It is a benefit of OS X... along with other benefits.

OS X is the second least obscure out there. It's not quite the bottom of the
security-by-obscurity barrel, but it's close!

So far good enough... but that might change. Slade says it will any day
now... and has been saying so for years. :)

[snip]
UAC dialogs aren't particularly wordy, really. But you really feel they are
useless, they can be turned off. In both Vista and Win7.

Yes... but I am not going to change settings on every computer I work with.

Nor should you. UAC was never as bad as Apple told you it was, anyway. :/

It was annoying.

Granted, I am often installing software and the like - the
average user might not see it as frequently as I do.

You'll still see UAC in Windows 7 when you install software.

One. I find it a lot less annoying than Vista.

"One"? One what?

One "are you sure" dialog as you go to install a program. That is fine.

I also would have missed out on the new taskbar... which is interesting.

You'd have the old one. Which was better. :(

In your view. We shall see how things work out in the long run. I will say,
right now I have mine set to show individual windows, but I still like the
application grouping and the launcher being tied to it.

I'm toughing it out for now. I always say you shouldn't hit the greybeard
switching, but should use the OS the way it was designed to be used.

But the temptation is very strong.

I am back to the default. Might play a bit. Will likely stick with the
default - I use Windows to make screencasts and try to stay mostly "typical"
with it.

[snip]
Yep. There is clearly an attempt at application-centricity going on.

There is no way, that I can see, to make it be anything other than apps -
though you can make the app area show its windows.

It won't group on anything else. I do not entirely approve of this, as you
know.

Right - the taskbar is now an application bar, really.

[snip]
This is not odd: it would be broken otherwise. Processes are an
implementation detail that should not be exposed to the user. The new
taskbar at least avoids that particular fault of OS X. We should be thankful
for small favors!

On OS X you do not launch a separate instance of a GUI app... other than if
you have a separate copy of it.

Yes, but on OS X the process is represented directly in the UI via Dock icons.
You even have to manually shut them down, in some cases.

Not sure what you are getting at... having apps running without open
windows?



--
[INSERT .SIG HERE]


.

Relevant Pages

  • Re: KB916281 cant install
    ... Make sure the Administrators group has Full Control permissions to the Auto ... Update registry key. ... Use an account that has administrative credentials to log on to the Windows ... access the Windows Update site, the data value should be a zero "0". ...
    (microsoft.public.windowsupdate)
  • Re: Unnown process... 5eplorer.exe
    ... do not remove the cause (a "super"-hidden .dll program) but only remove ... symptom files and registry settings. ... It has all permissions but 'copy' denied to everyone, ... then by using the Windows XP Recovery Console. ...
    (microsoft.public.win2000.general)
  • Re: 0X80070005 Error code
    ... Make sure the Administrators group has Full Control permissions to the Auto Update ... Use an account that has administrative credentials to log on to the Windows XP ... Navigate to the following key in the registry: ...
    (microsoft.public.windowsupdate)
  • RE: Error 1402
    ... >Microsoft Corporation ... >>This is a permissions issue that must be fixed through ... >>the Windows operating system. ... >>Do not use the registry key given in the Microsoft ...
    (microsoft.public.windowsxp.security_admin)
  • Re: OT: Win 7 comments
    ... auto-upgraded to new standard dialogs, ... right - this has been a problem for a long time on Windows. ... When the Registry goes belly up you are toast... ... I will wait for some apps to crash. ...
    (comp.sys.mac.advocacy)