I've been running the 64-bit version of Windows 7 RC since June.
It's been quite painless on the whole.
One wrinkle that I ran into was with some batchfiles which
launch applications in %ProgramFiles% (normally C:\Program Files).
Due to the magic WOW64 redirector, 32-bit applications
are actually installed into %ProgramFiles(x86)%—normally C:\Program Files (x86)—instead of %ProgramFiles%.
This is transparent to the 32-bit applications,
which think they're running in %ProgramFiles% (C:\Program Files).
However, the cmd.exe shell is 64-bit
(unless you make a special effort to run the 32-bit cmd.exe in SysWOW64),
so batchfiles see the 64-bit %ProgramFiles% which contains 64-bit applications.
Hence, a batchfile that launches an installed 32-bit application on Win64
must use %ProgramFiles(x86)%, not %ProgramFiles%.
It sounds trivial to have a batchfile detect
which flavor of %ProgramFiles% it should use,
but the parentheses in the environment variable name make it tricky to parse.
On earlier versions of Win64, the environment variable was called %ProgramFilesx86%.
Presumably they added the strange parentheses into the variable name
because the directory name always included them.
Here's a tiny batchfile that will launch the 32-bit DiffMerge
correctly on both Win64 and Win32 platforms.
@setlocal
@set _pf=%ProgramFiles%
@if not "[%ProgramFiles(x86)%]"=="[]" set _pf=%ProgramFiles(x86)%
@start "" /b "%_pf%\SourceGear\DiffMerge\DiffMerge.exe" %*
I long ago found that the safest way to test environment variables
whose values may include spaces, is to surround them with
both double quotes and square brackets.
I had about 60 apparently corrupted photos on a CompactFlash card the other evening.
It might have been due to Lightroom going berserk,
but it was more likely from my pulling the card reader out of the computer
without ejecting it first.
The photos wouldn't show up under Mac, Linux, or Windows.
I tried to chkdsk the card under Windows, which complained about a “raw” disk.
That led me to ZAR, the Zero Assumption Recovery toolkit.
The evaluation copy retrieved the photos very nicely.
Whew!
To my tech supportees:
XKCD's Tech Support Cheat Sheet nails it!
This is essentially what I'm doing when I sit down
at your computer and dig you out of your latest hole.
If only you'd make some more intelligent guesses for yourself,
you might be able to solve more of your problems.
But it's not quite that simple.
You probably don't understand very much about what you're doing.
I have enormous depth and breadth of experience which informs my investigation.
I am—no false modesty here—a master of debugging.
The extra context helps me hone in on a solution more often than not.
Still, do give the flowchart a shot.
Being able to solve your own problems is very empowering.
When using Lightroom before, I was never able to figure out how
to move photos from one folder to another.
You'd think that you could just click on a photo and drag it.
I just spent twenty minutes figuring out what I've been doing wrong.
After you've selected multiple photos,
click on the photo thumbnail and not the surrounding gray frame,
and then you can drag the photos to the target folder.
I had become accustomed to clicking on the frames to multi-select photos,
so naturally I assumed that was also how you dragged a set of photos.
But clicking on a frame of a selected photo merely deselects all the other photos.
I mentioned three weeks ago that I had just repaved my work dev box
and installed the 64-bit version of the Windows 7 RC.
Nine or ten years after I first ported parts of IIS to Win64,
I am finally running my main desktop on 64-bit Windows.
With one exception, it's been painless.
Programs have just worked, devices have just worked.
There are relatively few native x64 applications,
but for the most part it doesn't matter.
The cases where it does matter—e.g., shell extensions such as TortoiseSVN—are available as 64-bit binaries.
I briefly flirted with using the 64-bit build of Python,
but realized that I would have to recompile several eggs as 64-bit binaries.
That was too painful and the 32-bit binary did everything I needed.
Building in Visual Studio 2005 is noticeably faster.
I'm not sure how much of it was due to accumulated cruft after 18 months on Vista,
but builds there were very slow.
The one exception was a major problem for the first week and a half.
Whenever I ran our ASP.NET web application,
it would go berserk, eat up all 4GB of my physical RAM,
push the working set of IIS's w3wp.exe to 12GB,
and max out one of my 4 cores!
The only way to maintain any sanity was to run iisreset
every 20 minutes to gently kill the process.
WinDbg and Process Explorer showed that the rogue thread was stuck in a loop in
mscorjit!LifetimesListInteriorBlocksHelperIterative<GCInfoLiveRecordManipulator>.
I passed a minidump on to my former colleagues in IIS, who sent it to the CLR team.
They said:
The only thing I can tell is that it is Regex,
and some regex expression compiled down to a method with 456KB of IL.
That is huge, and yes 12GB of RAM consumed for something like that is expected.
With that clue, I was able to track down the problem,
a particularly foul regex, built from a 10KB string, with 32 alternating expressions,
each of which contains dozens of alternated subexpressions.
The string is built from many smaller strings,
so it's not obvious in the source just how ugly it is.
I commented out the new Regex() and my problems went away.
Regardless of how ugly the regex is, this is a major regression in the CLR.
This code has been working without blatant problems for two years
on the 32-bit flavors of XP, Server 2003, Vista, and Server 2008.
I've been meaning to try this code on 32-bit Windows 7,
but have been too busy.
(The original, long-gone author was apparently aware that the regex
is expensive to create because he runs a background thread to new the regex,
which should have told him something.
We'll fix the code that uses the regex to do something saner, soon.)
All that aside, I've been happy with the 64-bit version of Windows 7.
I complained a week ago about my display driver going berserk.
I blamed Windows Update, since it happened within hours of a pile of updates being installed.
I upgraded to the latest beta NVidia drivers on Monday
and it helped for a while, but by Wednesday,
it was almost as bad again as it had been last Friday.
It was infuriating and I was both entertaining and alarming my neighbors
with my cursing.
Today was the last day of a very busy sprint for me
and at last I had the time to dig into it.
I opened up the case and took a look at both video cards—I have two dual-head cards connected to three monitors—and one of them had partially blown capacitors like those in the picture.
I removed the bad card and did some graphics-intensive things for an hour,
and the other card behaved flawlessly.
Oddly, until someone mentioned that it might be a hardware problem yesterday,
it didn't occur to me, even though a video card blew in this machine last year.
I came in one morning to find a black monitor, and when I pulled out that card,
I found that some of the capacitors had popped right open with stuffing protruding.
On general principles, I had been meaning to repave this machine for a while.
I've had it since December 2007
and it was still running the original installation of Vista.
I booted from a DVD, reformatted my C: drive, and installed Windows 7 x64 RC1.
I finally have a 64-bit OS as my primary Windows desktop,
so I'll actually be using the Win64 build of Vim that I maintain.
My first impressions of Windows 7 on this machine are very favorable,
but there's plenty more that I need to install
before the machine has everything that I need.
This morning, the video adapters on my Vista dev box were resetting
2–3 times per minute.
After a pile of Windows Updates landed on my machine at 3am yesterday,
it would occasionally freeze solid for a few seconds.
Once in a while, all the monitors would go black briefly, then restore.
Each time, I would see a status update pop up from the system tray,
"Display driver nvlddmkm stopped responding and has successfully recovered."
This was irritating enough that I downloaded the latest NVidia drivers this morning,
185.85_desktop_winvista_32bit_english_whql.exe.
That really screwed me.
The video adapters started resetting 2–3 times per minute,
rendering the machine almost unusable.
I have two video adapters, NVidia GeForce 8600 GT and NVidia GeForce 7600 GT.
The eventlog was full of Event ID 4101 - Display Driver Timeout Detection and Recovery.
I reverted to the 178.24 drivers and that helped.
When I'm not touching the machine,
the adapters only get reset every few minutes instead of several times a minute.
When I am using it, something as simple as clicking a window
to bring it to the foreground can trigger a reset.
It's very irritating but I can live with it for a little while, unlike the other.
I don't want to repave my box: apart from the time loss,
I'm not convinced that it would help if I got the same driver config all over again.
I contacted a friend at Microsoft who tried to hook me up with a driver guy,
who is unfortunately out of office.
I'm hoping that it can be fixed early next week
or my temper is going to fray rapidly.
Update: June 19th: See When Video Cards Go Bad.
I updated the Win64 binaries of Vim at vim-win3264
from Vim 7.2.000 to 7.2.182.
I'm amazed that the original binaries were downloaded over 11,000 times
since last August.
I mentioned CrossLoop before, as a tool for remotely helping someone out.
It uses VNC to share desktops.
The last time I looked, it was Windows only.
Now there's a Mac client too.
I had to use it to help my father out in Dublin.
Somehow he had managed to delete both Adobe Reader and Adobe Flash—I haven't figured out how.
It was painful, painful, painful.
The connection was dropped repeatedly
and the link couldn't begin to keep up with the amount of graphical data being transferred.
Even though CrossLoop reduces the color depth,
actions like switching tabs in Firefox cause huge amounts of data to be sent.
I couldn't tell why the connection was being dropped.
There are so many places where things could go wrong:
my client, my connection, the CrossLoop server, his connection, his client,
some random router.
All in all, it took about 90 minutes,
but it would likely have been even longer and more confusing
without a shared desktop.
I tried Safari 4 on my MacBook back in February when it first came out in beta.
It crashed immediately, every time, so I uninstalled it.
I upgraded to OS X 10.5.7 earlier in the week and new Safari bits were available,
so it seemed like a good time to retry it.
After all, it had been faster than any other browser on my Vista box at work.
Again, it crashed immediately.
This time, however, I took a closer look at the details of the
error report that was being sent to Apple.
A little Googling suggested that the Glims plugin was at fault.
Indeed it was.
I replaced beta 8 from September 2008 with the new beta 16,
and it's working again.
Glims adds search engines, thumbnails in search results, favicons in tabs, etc.,
so it's useful.
I haven't used Safari 4 much yet on the Mac,
but it seems like an improvement.
More Posts
« Previous page -
Next page »